Screen On/Off Data

Introduction

Screen data refers to the information about the status of the screen as reported by Android. These data can reveal important information about people’s circadian rhythm, social patterns, and activity. Screen data is an event data, this means that it cannot be sampled at a regular frequency. We just have information about the events that occured. However, some factors may interfere with the correct detection of all events (e.g. when the phone’s battery is depleated). Therefore, to correctly process screen data, we need to take into account other information like the battery status of the phone. This may complicate the preprocessing. To address this, niimpy includes a set of functions to clean, downsample, and extract features from screen data while taking into account factors like the battery level. The functions allow us to extract the following features:

  • screen_off: reports when the screen has been turned off

  • screen_count: number of times the screen has turned on, off, or has been in use

  • screen_duration: duration in seconds of the screen on, off, and in use statuses

  • screen_duration_min: minimum duration in seconds of the screen on, off, and in use statuses

  • screen_duration_max: maximum duration in seconds of the screen on, off, and in use statuses

  • screen_duration_median: median duration in seconds of the screen on, off, and in use statuses

  • screen_duration_mean: mean duration in seconds of the screen on, off, and in use statuses

  • screen_duration_std: standard deviation of the duration in seconds of the screen on, off, and in use statuses

  • screen_first_unlock: reports the first time when the phone was unlocked every day

  • extract_features_screen: wrapper-like function to extract several features at the same time

In addition, the screen module has three internal functions that help classify the events and calculate their status duration.

In the following, we will analyze screen data provided by niimpy as an example to illustrate the use of screen data.

2. Read data

Let’s start by reading the example data provided in niimpy. These data have already been shaped in a format that meets the requirements of the data schema. Let’s start by importing the needed modules. Firstly we will import the niimpy package and then we will import the module we will use (screen) and give it a short name for use convenience.

[1]:
import niimpy
from niimpy import config
import niimpy.preprocessing.screen as s
import pandas as pd
import warnings
warnings.filterwarnings("ignore")

Now let’s read the example data provided in niimpy. The example data is in csv format, so we need to use the read_csv function. When reading the data, we can specify the timezone where the data was collected. This will help us handle daylight saving times easier. We can specify the timezone with the argument tz. The output is a dataframe. We can also check the number of rows and columns in the dataframe.

[2]:
data = niimpy.read_csv(config.MULTIUSER_AWARE_SCREEN_PATH, tz='Europe/Helsinki')
data.shape
[2]:
(277, 5)

The data was succesfully read. We can see that there are 277 datapoints with 5 columns in the dataset. However, we do not know yet what the data really looks like, so let’s have a quick look:

[3]:
data.head()
[3]:
user device time screen_status datetime
2020-01-09 02:06:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578528e+09 0 2020-01-09 02:06:41.573999872+02:00
2020-01-09 02:09:29.152000+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 1 2020-01-09 02:09:29.152000+02:00
2020-01-09 02:09:32.790999808+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 3 2020-01-09 02:09:32.790999808+02:00
2020-01-09 02:11:41.996000+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 0 2020-01-09 02:11:41.996000+02:00
2020-01-09 02:16:19.010999808+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 1 2020-01-09 02:16:19.010999808+02:00
[4]:
data.tail()
[4]:
user device time screen_status datetime
2019-09-08 17:17:14.216000+03:00 iGyXetHE3S8u Cq9vueHh3zVs 1.567952e+09 1 2019-09-08 17:17:14.216000+03:00
2019-09-08 17:17:31.966000128+03:00 iGyXetHE3S8u Cq9vueHh3zVs 1.567952e+09 0 2019-09-08 17:17:31.966000128+03:00
2019-09-08 20:50:07.360000+03:00 iGyXetHE3S8u Cq9vueHh3zVs 1.567965e+09 3 2019-09-08 20:50:07.360000+03:00
2019-09-08 20:50:08.139000064+03:00 iGyXetHE3S8u Cq9vueHh3zVs 1.567965e+09 1 2019-09-08 20:50:08.139000064+03:00
2019-09-08 20:53:12.960000+03:00 iGyXetHE3S8u Cq9vueHh3zVs 1.567965e+09 0 2019-09-08 20:53:12.960000+03:00

By exploring the head and tail of the dataframe we can form an idea of its entirety. From the data, we can see that:

  • rows are observations, indexed by timestamps, i.e. each row represents a screen event at a given time and date

  • columns are characteristics for each observation, for example, the user whose data we are analyzing

  • there are at least two different users in the dataframe

  • the main column is screen_status. This screen status is coded in numbers as: 0=off, 1=on, 2=locked, 3=unlocked.

* TIP! Data format requirements (or what should our data look like)

Data can take other shapes and formats. However, the niimpy data scheme requires it to be in a certain shape. This means the dataframe needs to have at least the following characteristics: 1. One row per screen status. Each row should store information about one screen status only 2. Each row’s index should be a timestamp 3. There should be at least three columns: - index: date and time when the event happened (timestamp) - user: stores the user name whose data is analyzed. Each user should have a unique name or hash (i.e. one hash for each unique user) - screen_status: stores the screen status (0,1,2, or 3) as defined by Android. 4. Columns additional to those listed in item 3 are allowed 5. The names of the columns do not need to be exactly “screen_status” as we can pass our own names in an argument (to be explained later).

Below is an example of a dataframe that complies with these minimum requirements

[5]:
example_dataschema = data[['user','screen_status']]
example_dataschema.head(3)
[5]:
user screen_status
2020-01-09 02:06:41.573999872+02:00 jd9INuQ5BBlW 0
2020-01-09 02:09:29.152000+02:00 jd9INuQ5BBlW 1
2020-01-09 02:09:32.790999808+02:00 jd9INuQ5BBlW 3

A few words on missing data

Missing data for screen is difficult to detect. Firstly, this sensor is triggered by events and not sampled at a fixed frequency. Secondly, different phones, OS, and settings change how the screen is turned on/off; for example, one phone may go from OFF to ON to UNLOCKED, while another phone may go from OFF to UNLOCKED directly. Thirdly, events not related to the screen may affect its behavior, e.g. battery running out. Neverthless, there are some events transitions that are impossible to have, like a status to itself (e.g. two consecutive 0s). These imposible statuses helps us determine the missing data.

A few words on the classification of the events

We can know the status of the screen at a certain timepoint. However, we need a bit more to know the duration and the meaning of it. Consequently, we need to look at the numbers of two consecutive events and classify the transitions (going from one state to another consecutively) as: - from 3 to 0,1,2: the phone was in use - from 1 to 0,1,3: the phone was on - from 0 to 1,2,3: the phone was off

Other transitions are irrelevant.

A few words on the role of the battery

As mentioned before, battery statuses can affect the screen behavior. In particular, when the battery is depleated and the phone is shut down automatically, the screen sensor does not cast any events, so even when the screen is technically OFF because the phone does not have any battery left, we will not see that 0 in the screen status column. Thus, it is important to take into account the battery information when analyzing screen data. niimpy’s screen module is adapted to take into account the battery data. Since we do have some battery data, we will load it.

[6]:
bat_data = niimpy.read_csv(config.MULTIUSER_AWARE_BATTERY_PATH, tz='Europe/Helsinki')
bat_data.head()
[6]:
user device time battery_level battery_status battery_health battery_adaptor datetime
2020-01-09 02:20:02.924999936+02:00 jd9INuQ5BBlW 3p83yASkOb_B 1.578529e+09 74 3 2 0 2020-01-09 02:20:02.924999936+02:00
2020-01-09 02:21:30.405999872+02:00 jd9INuQ5BBlW 3p83yASkOb_B 1.578529e+09 73 3 2 0 2020-01-09 02:21:30.405999872+02:00
2020-01-09 02:24:12.805999872+02:00 jd9INuQ5BBlW 3p83yASkOb_B 1.578529e+09 72 3 2 0 2020-01-09 02:24:12.805999872+02:00
2020-01-09 02:35:38.561000192+02:00 jd9INuQ5BBlW 3p83yASkOb_B 1.578530e+09 72 2 2 0 2020-01-09 02:35:38.561000192+02:00
2020-01-09 02:35:38.953000192+02:00 jd9INuQ5BBlW 3p83yASkOb_B 1.578530e+09 72 2 2 2 2020-01-09 02:35:38.953000192+02:00

In this case, we are interested in the battery_status information. This is standard information provided by Android. However, if the dataframe has this information in a column with a different name, we can use the argument battery_column_name similarly to the use of screen_column_name (more info about this topic below).

4. Extracting features

There are two ways to extract features. We could use each function separately or we could use niimpy’s ready-made wrapper. Both ways will require us to specify arguments to pass to the functions/wrapper in order to customize the way the functions work. These arguments are specified in dictionaries. Let’s first understand how to extract features using stand-alone functions.

We can use niimpy’s functions to compute communication features. Each function will require two inputs: - (mandatory) dataframe that must comply with the minimum requirements (see ‘* TIP! Data requirements above) - (optional) an argument dictionary for stand-alone functions

4.1.1 The argument dictionary for stand-alone functions (or how we specify the way a function works)

In this dictionary, we can input two main features to customize the way a stand-alone function works: - the name of the columns to be preprocessed: Since the dataframe may have different columns, we need to specify which column has the data we would like to be preprocessed. To do so, we can simply pass the name of the column to the argument screen_column_name.

  • the way we resample: resampling options are specified in niimpy as a dictionary. niimpy’s resampling and aggregating relies on pandas.DataFrame.resample, so mastering the use of this pandas function will help us greatly in niimpy’s preprocessing. Please familiarize yourself with the pandas resample function before continuing. Briefly, to use the pandas.DataFrame.resample function, we need a rule. This rule states the intervals we would like to use to resample our data (e.g., 15-seconds, 30-minutes, 1-hour). Neverthless, we can input more details into the function to specify the exact sampling we would like. For example, we could use the close argument if we would like to specify which side of the interval is closed, or we could use the offset argument if we would like to start our binning with an offset, etc. There are plenty of options to use this command, so we strongly recommend having pandas.DataFrame.resample documentation at hand. All features for the pandas.DataFrame.resample will be specified in a dictionary where keys are the arguments’ names for the pandas.DataFrame.resample, and the dictionary’s values are the values for each of these selected arguments. This dictionary will be passed as a value to the key resample_args in niimpy.

Let’s see some basic examples of these dictionaries:

[7]:
feature_dict1:{"screen_column_name":"screen_status","resample_args":{"rule":"1D"}}
feature_dict2:{"screen_column_name":"random_name","resample_args":{"rule":"30T"}}
feature_dict3:{"screen_column_name":"other_name","resample_args":{"rule":"45T","origin":"end"}}

Here, we have three basic feature dictionaries.

  • feature_dict1 will be used to analyze the data stored in the column screen_status in our dataframe. The data will be binned in one day periods

  • feature_dict2 will be used to analyze the data stored in the column random_name in our dataframe. The data will be aggregated in 30-minutes bins

  • feature_dict3 will be used to analyze the data stored in the column other_name in our dataframe. The data will be binned in 45-minutes bins, but the binning will start from the last timestamp in the dataframe.

Default values: if no arguments are passed, niimpy’s default values are “screen_status” for the screen_column_name, and 30-min aggregation bins.

4.1.2 Using the functions

Now that we understand how the functions are customized, it is time we compute our first communication feature. Suppose that we are interested in extracting the total duration of outgoing calls every 20 minutes. We will need niimpy’s screen_count function, the data, and we will also need to create a dictionary to customize our function. Let’s create the dictionary first

[8]:
function_features={"screen_column_name":"screen_status","resample_args":{"rule":"20T"}}

Now let’s use the function to preprocess the data.

[9]:
my_screen_count = s.screen_count(data, bat_data, function_features)

Let’s look at some values for one of the subjects.

[10]:
my_screen_count[my_screen_count["user"] == "jd9INuQ5BBlW"]
[10]:
user device screen_on_count screen_off_count screen_use_count
2020-01-09 02:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 2 2 2
2020-01-09 02:20:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 3 4 2
2020-01-09 02:40:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 2 2 1
2020-01-09 03:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 0 0 0
2020-01-09 03:20:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 0 0 0
... ... ... ... ... ...
2020-01-09 21:40:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 1 1 0
2020-01-09 22:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 1 1 0
2020-01-09 22:20:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 0 0 0
2020-01-09 22:40:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 0 0 0
2020-01-09 23:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix 4 3 0

64 rows × 5 columns

Let’s remember how the original data looked like for this subject

[11]:
data[data["user"]=="jd9INuQ5BBlW"].head(7)
[11]:
user device time screen_status datetime
2020-01-09 02:06:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578528e+09 0 2020-01-09 02:06:41.573999872+02:00
2020-01-09 02:09:29.152000+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 1 2020-01-09 02:09:29.152000+02:00
2020-01-09 02:09:32.790999808+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 3 2020-01-09 02:09:32.790999808+02:00
2020-01-09 02:11:41.996000+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 0 2020-01-09 02:11:41.996000+02:00
2020-01-09 02:16:19.010999808+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 1 2020-01-09 02:16:19.010999808+02:00
2020-01-09 02:16:29.648999936+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 0 2020-01-09 02:16:29.648999936+02:00
2020-01-09 02:16:29.657999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 1.578529e+09 2 2020-01-09 02:16:29.657999872+02:00

We see that the bins are indeed 20-minutes bins, however, they are adjusted to fixed, predetermined intervals, i.e. the bin does not start on the time of the first datapoint. Instead, pandas starts the binning at 00:00:00 of everyday and counts 20-minutes intervals from there.

If we want the binning to start from the first datapoint in our dataset, we need the origin parameter and a for loop.

[12]:
users = list(data['user'].unique())
results = []
for user in users:
    start_time = data[data["user"]==user].index.min()
    function_features={"screen_column_name":"screen_status","resample_args":{"rule":"20T","origin":start_time}}
    results.append(s.screen_count(data[data["user"]==user],bat_data[bat_data["user"]==user], function_features))
my_screen_count = pd.concat(results)
[13]:
my_screen_count
[13]:
user device screen_on_count screen_off_count screen_use_count
2020-01-09 02:06:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 4 3 3
2020-01-09 02:26:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 2 3 1
2020-01-09 02:46:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 2 2 1
2020-01-09 03:06:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 0 0 0
2020-01-09 03:26:41.573999872+02:00 jd9INuQ5BBlW OWd1Uau8POix 0 0 0
... ... ... ... ... ...
2019-09-08 19:22:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-09-08 19:42:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-09-08 20:02:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-09-08 20:22:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-09-08 20:42:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 1

2533 rows × 5 columns

The functions can also be called in absence of a config dictionary. In this case, the binning will be automatically set to 30-minutes.

[14]:
my_screen_count = s.screen_count(data, bat_data, {})
my_screen_count.head()
[14]:
user device screen_on_count screen_off_count screen_use_count
2019-08-05 14:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 4 4 4
2019-08-05 14:30:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 2 2 2
2019-08-05 15:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-08-05 15:30:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-08-05 16:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0

In case we do not have battery data, the functions can also be called without it. In this case, simply input an empty dataframe in the second position of the function. For example,

[15]:
empty_bat = pd.DataFrame()
no_bat = s.screen_count(data, empty_bat, function_features) #no battery information
no_bat.head()
[15]:
user device screen_on_count screen_off_count screen_use_count
2019-08-05 14:02:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 3 3 3
2019-08-05 14:22:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 2 2 2
2019-08-05 14:42:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 1 1 1
2019-08-05 15:02:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0
2019-08-05 15:22:41.009999872+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0 0 0

4.2 Extract features using the wrapper

We can use niimpy’s ready-made wrapper to extract one or several features at the same time. The wrapper will require two inputs: - (mandatory) dataframe that must comply with the minimum requirements (see ‘* TIP! Data requirements above) - (optional) an argument dictionary for wrapper

4.2.1 The argument dictionary for wrapper (or how we specify the way the wrapper works)

This argument dictionary will use dictionaries created for stand-alone functions. If you do not know how to create those argument dictionaries, please read the section 4.1.1 The argument dictionary for stand-alone functions (or how we specify the way a function works) first.

The wrapper dictionary is simple. Its keys are the names of the features we want to compute. Its values are argument dictionaries created for each stand-alone function we will employ. Let’s see some examples of wrapper dictionaries:

[16]:
wrapper_features1 = {s.screen_count:{"screen_column_name":"screen_status","resample_args":{"rule":"1D"}},
                     s.screen_duration_min:{"screen_column_name":"screen_status","resample_args":{"rule":"1D"}}}
  • wrapper_features1 will be used to analyze two features, screen_count and screen_duration_min. For the feature screen_count, we will use the data stored in the column screen_status in our dataframe and the data will be binned in one day periods. For the feature screen_duration_min, we will use the data stored in the column screen_status in our dataframe and the data will be binned in one day periods.

[17]:
wrapper_features2 = {s.screen_count:{"screen_column_name":"screen_status", "battery_column_name":"battery_status", "resample_args":{"rule":"1D"}},
                     s.screen_duration:{"screen_column_name":"random_name","resample_args":{"rule":"5H","offset":"5min"}}}
  • wrapper_features2 will be used to analyze two features, screen_status and screen_duration. For the feature screen_status, we will use the data stored in the column screen_status in our dataframe and the data will be binned in one day periods. In addition, we will use battery data stored in a column called “battery_status”. For the feature screen_duration, we will use the data stored in the column random_name in our dataframe and the data will be binned in 5-hour periods with a 5-minute offset.

[18]:
wrapper_features3 = {s.screen_count:{"screen_column_name":"one_name","resample_args":{"rule":"1D","offset":"5min"}},
                     s.screen_duration:{"screen_column_name":"one_name", "battery_column":"some_column","resample_args":{}},
                     s.screen_duration_min:{"screen_column_name":"another_name","resample_args":{"rule":"30T","origin":"end_day"}}}
  • wrapper_features3 will be used to analyze three features, screen_count, screen_duration, and screen_duration_min. For the feature screen_count, we will use the data stored in the column one_name and the data will be binned in one day periods with a 5-min offset. For the feature screen_duration, we will use the data stored in the column one_name in our dataframe and the data will be binned using the default settings, i.e. 30-min bins. In addition, we will use data from the battery sensor, which will be passed in a column called “some_column”. Finally, for the feature screen_duration_min, we will use the data stored in the column another_name in our dataframe and the data will be binned in 30-minute periods and the origin of the bins will be the ceiling midnight of the last day.

Default values: if no arguments are passed, niimpy’s default values are “screen_status” for the screen_column_name, and 30-min aggregation bins. Moreover, the wrapper will compute all the available functions in absence of the argument dictionary.

4.2.2 Using the wrapper

Now that we understand how the wrapper is customized, it is time we compute our first communication feature using the wrapper. Suppose that we are interested in extracting the call total duration every 50 minutes. We will need niimpy’s extract_features_comms function, the data, and we will also need to create a dictionary to customize our function. Let’s create the dictionary first

[19]:
wrapper_features1 = {s.screen_duration:{"screen_column_name":"screen_status","resample_args":{"rule":"50T"}}}

Now, let’s use the wrapper

[20]:
results_wrapper = s.extract_features_screen(data, bat_data, features=wrapper_features1)
results_wrapper.head(5)
[20]:
user device screen_on_durationtotal screen_off_durationtotal screen_use_durationtotal
2019-08-05 13:20:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 78.193 546.422 0.139
2019-08-05 14:10:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 198.189 286720.506 1.050
2019-08-05 15:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000 0.000
2019-08-05 15:50:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000 0.000
2019-08-05 16:40:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000 0.000

Our first attempt was succesful. Now, let’s try something more. Let’s assume we want to compute the screen_duration and screen_count in 50-minutes bin.

[21]:
wrapper_features2 = {s.screen_duration:{"screen_column_name":"screen_status","resample_args":{"rule":"50T"}},
                     s.screen_count:{"screen_column_name":"screen_status","resample_args":{"rule":"50T"}}}
results_wrapper = s.extract_features_screen(data, bat_data, features=wrapper_features2)
results_wrapper.head(5)
[21]:
user device screen_on_durationtotal screen_off_durationtotal screen_use_durationtotal screen_on_count screen_off_count screen_use_count
2019-08-05 13:20:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 78.193 546.422 0.139 1 1 1
2019-08-05 14:10:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 198.189 286720.506 1.050 5 5 5
2019-08-05 15:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000 0.000 0 0 0
2019-08-05 15:50:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000 0.000 0 0 0
2019-08-05 16:40:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000 0.000 0 0 0

Great! Another successful attempt. We see from the results that more columns were added with the required calculations. This is how the wrapper works when all features are computed with the same bins. Now, let’s see how the wrapper performs when each function has different binning requirements. Let’s assume we need to compute the screen_duration every day, and the screen_count every 5 hours with an offset of 5 minutes.

[22]:
wrapper_features3 = {s.screen_duration:{"screen_column_name":"screen_status","resample_args":{"rule":"1D"}},
                     s.screen_count:{"screen_column_name":"screen_status","resample_args":{"rule":"5H","offset":"5min"}}}
results_wrapper = s.extract_features_screen(data, bat_data, features=wrapper_features3)
results_wrapper.head(5)
[22]:
user device screen_on_durationtotal screen_off_durationtotal screen_use_durationtotal screen_on_count screen_off_count screen_use_count
2019-08-05 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 276.382 287266.927999 1.189 NaN NaN NaN
2019-08-06 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000000 0.000 NaN NaN NaN
2019-08-07 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 0.000 0.000000 0.000 NaN NaN NaN
2019-08-08 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 98.228 34238.356000 2.866 NaN NaN NaN
2019-08-09 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 8.136 114869.103000 0.516 NaN NaN NaN
[23]:
results_wrapper.tail(5)
[23]:
user device screen_on_durationtotal screen_off_durationtotal screen_use_durationtotal screen_on_count screen_off_count screen_use_count
2020-01-09 00:05:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN NaN NaN 7.0 8.0 5.0
2020-01-09 05:05:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN NaN NaN 0.0 0.0 0.0
2020-01-09 10:05:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN NaN NaN 9.0 9.0 3.0
2020-01-09 15:05:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN NaN NaN 17.0 17.0 7.0
2020-01-09 20:05:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN NaN NaN 12.0 11.0 3.0

The output is once again a dataframe. In this case, two aggregations are shown. The first one is the daily aggregation computed for the screen_duration feature (head). The second one is the 5-hour aggregation period with 5-min offset for the screen_count (tail). We must note that because the screen_countfeature is not required to be aggregated daily, the daily aggregation timestamps have a NaN value. Similarly, because the screen_durationis not required to be aggregated in 5-hour windows, its values are NaN for all subjects.

4.2.3 Wrapper and its default option

The default option will compute all features in 30-minute aggregation windows. To use the extract_features_comms function with its default options, simply call the function.

[24]:
default = s.extract_features_screen(data, bat_data)

The function prints the computed features so you can track its process. Now let’s have a look at the outputs

[25]:
default.tail(10)
[25]:
user device screen_off screen_on_count screen_off_count screen_use_count screen_on_durationtotal screen_off_durationtotal screen_use_durationtotal screen_on_durationminimum ... screen_on_durationmean screen_off_durationmean screen_use_durationmean screen_on_durationmedian screen_off_durationmedian screen_use_durationmedian screen_on_durationstd screen_off_durationstd screen_use_durationstd first_unlock
2020-01-09 19:30:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 0.0 0.0 0.0 0.000 0.000000 0.000 NaN ... NaN NaN NaN NaN NaN NaN NaN NaN NaN NaT
2020-01-09 20:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 0.0 0.0 0.0 0.000 0.000000 0.000 NaN ... NaN NaN NaN NaN NaN NaN NaN NaN NaN NaT
2020-01-09 20:30:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 1.0 1.0 1.0 8.253 0.005000 28.930 8.253 ... 8.253000 0.005000 28.930 8.2530 0.005 28.930 NaN NaN NaN NaT
2020-01-09 21:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 2.0 1.0 1.0 11.158 0.010000 39.087 5.234 ... 5.579000 0.010000 39.087 5.5790 0.010 39.087 0.487904 NaN NaN NaT
2020-01-09 21:30:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 4.0 5.0 1.0 376.930 46.027999 101.062 33.834 ... 94.232500 9.205600 101.062 73.2835 0.012 101.062 71.990324 20.561987 NaN NaT
2020-01-09 22:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 1.0 1.0 0.0 154.643 0.011000 NaN 154.643 ... 154.643000 0.011000 NaN 154.6430 0.011 NaN NaN NaN NaN NaT
2020-01-09 22:30:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 0.0 0.0 0.0 0.000 0.000000 NaN NaN ... NaN NaN NaN NaN NaN NaN NaN NaN NaN NaT
2020-01-09 23:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN 4.0 3.0 0.0 6.931 0.025000 NaN 2.079 ... 2.310333 0.008333 NaN 2.2620 0.008 NaN 0.258906 0.000577 NaN NaT
2019-08-05 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs NaN NaN NaN NaN NaN NaN NaN NaN ... NaN NaN NaN NaN NaN NaN NaN NaN NaN 2019-08-05 14:03:42.322000128+03:00
2020-01-09 00:00:00+02:00 jd9INuQ5BBlW OWd1Uau8POix NaN NaN NaN NaN NaN NaN NaN NaN ... NaN NaN NaN NaN NaN NaN NaN NaN NaN 2020-01-09 02:16:19.010999808+02:00

10 rows × 25 columns

Implementing own features

If none of the provided functions suits well, We can implement our own customized features easily. To do so, we need to define a function that accepts a dataframe and returns a dataframe. The returned object should be indexed by user and timestamps (multiindex). To make the feature readily available in the default options, we need add the screen prefix to the new function (e.g. screen_my-new-feature). Let’s assume we need a new function that detects the last time the screen is unlocked. Let’s first define the function

[26]:
def screen_last_unlock(df, bat, config=None):
    if not "screen_column_name" in config:
        col_name = "screen_status"
    else:
        col_name = config["screen_column_name"]
    if not "resample_args" in config.keys():
        config["resample_args"] = {"rule":"30T"}

    df2 = s.util_screen(df, bat, config)
    df2 = s.event_classification_screen(df2, config)

    df2["time"] = df2.index
    result = df2[df2.on==1].groupby(["user", "device"])["time"].resample(rule='1D').max()
    result = result.to_frame(name="first_unlock")
    result = result.reset_index(["user", "device"])

    return result

Then, we can call our new function in the stand-alone way or using the extract_features_screen function. Because the stand-alone way is the common way to call functions in python, we will not show it. Instead, we will show how to integrate this new function to the wrapper. Let’s read again the data and assume we want the default behavior of the wrapper.

[27]:
customized_features = s.extract_features_screen(data, bat_data, features={screen_last_unlock: {}})
[28]:
customized_features.head()
[28]:
user device first_unlock
2019-08-05 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 2019-08-05 14:49:45.596999936+03:00
2019-08-06 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs NaT
2019-08-07 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs NaT
2019-08-08 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 2019-08-08 22:44:13.834000128+03:00
2019-08-09 00:00:00+03:00 iGyXetHE3S8u Cq9vueHh3zVs 2019-08-09 07:50:33.224000+03:00