Predicting Which Users will Login at a particular time

Question

I have a challenging use case at work.

We have logs of which user login at which times. So, consider 7 days a week, 24 hours. We have to map these 7x24 slots to different users.

I am trying to figure out how to apply Machine learning here.

Users are in thousands, so not sure if classification will work.

If t is a variable, then it has 7*24 potential values, at any hour there can be multiple users logging in.

I can't figure out in which category this problem belongs to. Any tutorials, algorithms or frameworks are welcome.

Thanks.

Answer 1

I assume you have a table like this:

user |           timestamp |  event
   1 | 2000-01-01 18:00:00 |  login
   2 | 2000-01-01 19:00:00 |  login
   3 | 2000-01-01 20:00:00 |  login
   3 | 2000-01-01 22:00:00 | logout
   2 | 2000-01-01 23:00:00 | logout
   1 | 2000-01-01 23:30:00 | logout
   1 | 2000-01-02 19:30:00 |  login
   2 | 2000-01-02 19:45:00 |  login
   3 | 2000-01-02 20:00:00 |  login
   ...

and maybe some other table holding information about the users (geographic/age/gender/...)

The goal is to predict when which user will login (and maybe logout ?).

The minimal approach I would go is to do the following two steps:

1. Reduce this problem to a usual regression problem à la survival analysis: "How long does ot take until the object (user) has its event (next login)?".
2. Think about and add features that resemble the usual login/logout behavior.

The first step simply consists of converting the table above into the following way: For every logout event you add the information 'how long does it take until the user will login again?'. I.e. first of all you add 'next login ts' like this:

user |           timestamp |  event |       next_login_ts
   1 | 2000-01-01 18:00:00 |  login |                  NA
   2 | 2000-01-01 19:00:00 |  login |                  NA
   3 | 2000-01-01 20:00:00 |  login |                  NA
   3 | 2000-01-01 22:00:00 | logout | 2000-01-02 19:30:00
   2 | 2000-01-01 23:00:00 | logout | 2000-01-02 19:45:00
   1 | 2000-01-01 23:30:00 | logout | 2000-01-02 20:00:00
   1 | 2000-01-02 19:30:00 |  login |                  NA
   2 | 2000-01-02 19:45:00 |  login |                  NA
   3 | 2000-01-02 20:00:00 |  login |                  NA
   ...

then you filter for the logout events and compute the difference from timestamp to next_login_ts is some unit like minutes like this:

user |           timestamp |  event |       next_login_ts | diff_minutes
   3 | 2000-01-01 22:00:00 | logout | 2000-01-02 19:30:00 |         1290
   2 | 2000-01-01 23:00:00 | logout | 2000-01-02 19:45:00 |         1245
   1 | 2000-01-01 23:30:00 | logout | 2000-01-02 20:00:00 |         1230

This will be your training set with target variable diff_minutes. This was the easy part.

The second step consists of getting as much information as possible about the user and everything that could influence his/her login/logout behavior into the table. Examples:

• Simple facts about the user (like gender, age, geo info) could help but (according to my experience) are mostly useless if they are not connected somehow to the behavior that we want to measure. I.e. the feature 'age' could be transformed into something involving age profiles like 'the target group '18-24 years old' like to login at the morning and at the evening and the target group '30+' likes to log in only at the weekend...
• How long does it usually take until this user logs in for the next time (rolling window over the last k periods between logout and next login)?
• At which hour does the usual normally log in? I.e. do a little profiling if possible: Is it a user that likes to use the app when riding the train while commuting to/from work? Or is the user a typical weekend user? Here it may be helpful to apply some unsupervised learning algorithm as a preprocessing step in order to do this profiling automatically.

Generally you could theoretically try to add a 'usual' tranformation for every feature like this: "How long does it take for users at the age of the currently considered user until they log in again?". Be aware however that these features usually have a hogh correlation (to the target variable as well to each other) so after you have used one or two of these features you should not add more in order to make the model be able to 'explore' other features, i.e. if you only add these 'usual' features then it could happen that the model focusses on them and does not use the other features which might have potential. Or you could also add in all of them and then use some kind of feature selection like PCA.

General advice: try many ways and try to interpret the results.

Example: In one of my projects we had interesting data about the events but all the performance came from these 'usual' features. That means that usually, everything is as it was before and if there are outliers then the model is not able to detect them or the data did not contain any information from which the model was able to distinguish outliers from usual events.

Good Luck :-)