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 offscreen_count
: number of times the screen has turned on, off, or has been in usescreen_duration
: duration in seconds of the screen on, off, and in use statusesscreen_duration_min
: minimum duration in seconds of the screen on, off, and in use statusesscreen_duration_max
: maximum duration in seconds of the screen on, off, and in use statusesscreen_duration_median
: median duration in seconds of the screen on, off, and in use statusesscreen_duration_mean
: mean duration in seconds of the screen on, off, and in use statusesscreen_duration_std
: standard deviation of the duration in seconds of the screen on, off, and in use statusesscreen_first_unlock
: reports the first time when the phone was unlocked every dayextract_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 onpandas.DataFrame.resample
, so mastering the use of this pandas function will help us greatly inniimpy
’s preprocessing. Please familiarize yourself with the pandas resample function before continuing. Briefly, to use thepandas.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 havingpandas.DataFrame.resample
documentation at hand. All features for thepandas.DataFrame.resample
will be specified in a dictionary where keys are the arguments’ names for thepandas.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 keyresample_args
inniimpy
.
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 columnscreen_status
in our dataframe. The data will be binned in one day periodsfeature_dict2
will be used to analyze the data stored in the columnrandom_name
in our dataframe. The data will be aggregated in 30-minutes binsfeature_dict3
will be used to analyze the data stored in the columnother_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
andscreen_duration_min
. For the feature screen_count, we will use the data stored in the columnscreen_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 columnscreen_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
andscreen_duration
. For the feature screen_status, we will use the data stored in the columnscreen_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 columnrandom_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
, andscreen_duration_min
. For the feature screen_count, we will use the data stored in the columnone_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 columnone_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 columnanother_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_count
feature is not required to be aggregated daily, the daily aggregation timestamps have a NaN value. Similarly, because the screen_duration
is 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 |