Sorry for the basic question, but are we supposed to treat the following sort of user as non-fraudulent? They do download, but suspiciously too much. Do we just ignore that? (In my renamed fields, 'dload' -> 'is_attributed' etc.)
\n\n > tr[ip==5314&ap==72&dv==1&os==13&ch==101, ]\n ip ap dv os ch ctime atime dload L\n 5314 72 1 13 101 2017-11-07 00:55:41 2017-11-07 06:45:56 1 1\n 5314 72 1 13 101 2017-11-07 02:15:54 2017-11-07 03:08:38 1 2\n 5314 72 1 13 101 2017-11-07 08:47:37 2017-11-07 09:09:14 1 3\n 5314 72 1 13 101 2017-11-07 10:50:08 2017-11-07 11:37:13 1 4\n 5314 72 1 13 101 2017-11-07 12:42:50 <NA> 0 5\n 5314 72 1 13 101 2017-11-07 12:58:32 2017-11-07 13:09:06 1 6\n 5314 72 1 13 101 2017-11-07 13:23:07 2017-11-07 13:45:22 1 7\n 5314 72 1 13 101 2017-11-07 17:38:59 2017-11-07 23:06:31 1 8\n 5314 72 1 13 101 2017-11-08 07:42:02 2017-11-08 09:01:06 1 9\n 5314 72 1 13 101 2017-11-08 13:02:00 2017-11-08 13:03:54 1 10\n 5314 72 1 13 101 2017-11-08 14:00:28 <NA> 0 11\n 5314 72 1 13 101 2017-11-08 14:48:26 2017-11-08 15:30:57 1 12\n 5314 72 1 13 101 2017-11-08 21:52:07 2017-11-09 01:54:24 1 13\n 5314 72 1 13 101 2017-11-08 23:16:30 2017-11-09 00:00:36 1 14\n 5314 72 1 13 101 2017-11-09 08:35:13 2017-11-09 11:15:23 1 15\n 5314 72 1 13 101 2017-11-09 10:09:58 2017-11-09 10:35:00 1 16\n 5314 72 1 13 101 2017-11-09 12:15:51 2017-11-09 12:59:31 1 17\n 5314 72 1 13 101 2017-11-09 13:55:06 2017-11-09 14:05:34 1 18\n 5314 72 1 13 101 2017-11-09 15:06:08 <NA> 0 19\nSorry for the basic question, but are we supposed to treat the following sort of user as non-fraudulent? They do download, but suspiciously too much. Do we just ignore that? (In my renamed fields, 'dload' -> 'is_attributed' etc.)
\n\n > tr[ip==5314&ap==72&dv==1&os==13&ch==101, ]\n ip ap dv os ch ctime atime dload L\n 5314 72 1 13 101 2017-11-07 00:55:41 2017-11-07 06:45:56 1 1\n 5314 72 1 13 101 2017-11-07 02:15:54 2017-11-07 03:08:38 1 2\n 5314 72 1 13 101 2017-11-07 08:47:37 2017-11-07 09:09:14 1 3\n 5314 72 1 13 101 2017-11-07 10:50:08 2017-11-07 11:37:13 1 4\n 5314 72 1 13 101 2017-11-07 12:42:50 <NA> 0 5\n 5314 72 1 13 101 2017-11-07 12:58:32 2017-11-07 13:09:06 1 6\n 5314 72 1 13 101 2017-11-07 13:23:07 2017-11-07 13:45:22 1 7\n 5314 72 1 13 101 2017-11-07 17:38:59 2017-11-07 23:06:31 1 8\n 5314 72 1 13 101 2017-11-08 07:42:02 2017-11-08 09:01:06 1 9\n 5314 72 1 13 101 2017-11-08 13:02:00 2017-11-08 13:03:54 1 10\n 5314 72 1 13 101 2017-11-08 14:00:28 <NA> 0 11\n 5314 72 1 13 101 2017-11-08 14:48:26 2017-11-08 15:30:57 1 12\n 5314 72 1 13 101 2017-11-08 21:52:07 2017-11-09 01:54:24 1 13\n 5314 72 1 13 101 2017-11-08 23:16:30 2017-11-09 00:00:36 1 14\n 5314 72 1 13 101 2017-11-09 08:35:13 2017-11-09 11:15:23 1 15\n 5314 72 1 13 101 2017-11-09 10:09:58 2017-11-09 10:35:00 1 16\n 5314 72 1 13 101 2017-11-09 12:15:51 2017-11-09 12:59:31 1 17\n 5314 72 1 13 101 2017-11-09 13:55:06 2017-11-09 14:05:34 1 18\n 5314 72 1 13 101 2017-11-09 15:06:08 <NA> 0 19\nConversely if we look at their behavior across apps, their download behavior varies hugely by app, and looks mostly legit. So is this a legit customer? But still why do they download app=72 16 times out of 19 views?
\n\n> tr[ip==5314&dv==1&os==13&ch==101, list( tot_dload=sum(dload), tot_clicks=.N, dloads_per_click=mean(dload)), by=ap] [order(dloads_per_click)]\n\n ap tot_dload tot_clicks dloads_per_click\n 1 0 17 0.000000000\n 4 0 29 0.000000000\n 66 0 13 0.000000000\n 118 0 1 0.000000000\n 155 0 1 0.000000000\n 7 3 1155 0.002597403\n 92 3 11 0.272727273\n 29 1 3 0.333333333\n 244 2 4 0.500000000\n 39 5 7 0.714285714\n 72 16 19 0.842105263\n\n\n\n... but are we supposed to treat the following sort of user as non-fraudulent?
\n
Thing is, this contest asks us to estimate probability of a click resulting in a download (is_attributed==1). \nFrom the contest description:
\n\n\n\n\nFor each click_id in the test set, you must predict a probability for the target is_attributed variable.
\n
Therefore, I wouldn't worry much about suspicious 1's, as long as your solution gives them high probability.
", "rawMarkdown": "> ... but are we supposed to treat the following sort of user as non-fraudulent? \n\nThing is, this contest asks us to estimate probability of a click resulting in a download (is_attributed==1). \nFrom the contest description:\n> For each click_id in the test set, you must predict a probability for the target is_attributed variable.\n\nTherefore, I wouldn't worry much about suspicious 1's, as long as your solution gives them high probability.", "votes": null }, { "id": "317757", "postDate": "04/22/2018 13:36:23", "content": "One of the potential 'legit' scenarios might be a shopping mall with free wi-fi and a promotion going on in it - something like \"download our app and win discount, etc... blah blah\"
", "rawMarkdown": "One of the potential 'legit' scenarios might be a shopping mall with free wi-fi and a promotion going on in it - something like \"download our app and win discount, etc... blah blah\"", "votes": null }, { "id": "318562", "postDate": "04/24/2018 04:00:45", "content": "Right. We conclude the user download propensity varies strongly by app. And is presumably heavily influenced by the app type. viz. their behavior for app==72 is not necessarily fraud.
", "rawMarkdown": "Right. We conclude the user download propensity varies strongly by app. And is presumably heavily influenced by the app type. viz. their behavior for app==72 is not necessarily fraud.", "votes": null }, { "id": "318563", "postDate": "04/24/2018 04:01:54", "content": "...perhaps... but it's [EDIT: the competition is badly designed] if downloading multiple (16) times gives you 16 rewards, instead of one per IMEI.
", "rawMarkdown": "...perhaps... but it's [EDIT: the competition is badly designed] if downloading multiple (16) times gives you 16 rewards, instead of one per IMEI.", "votes": null }, { "id": "318661", "postDate": "04/24/2018 08:23:13", "content": "What I am saying is - it's not necessarily badly coded.
\nMy viewpoint is that 5314:72:1:13:101 should not be observed as a single user. The info that Ip : App : Device : Os : Channel combination gives us is not 'narrow' enough to observe it as a single user.
For example - take 19 people in a shopping mall with shared wifi (same ip). They are coming out of mobile shop, where they just purchased the most sold Android phone in China, hypothetically Samsung S9 (same device), with the factory default Android version installed (same os). \nNow, let's say that the first thing they want to do when they exit a shop is to download some very popular app that they frequently used on their old phone. So, they do a search on a very popular Baidu search engine and click an ad in the results (channel), in order to download (for example) WeChat app (same app). Now, since we are talking about China, imagine this in a huge shopping mall in some of the huge Chinese cities, where enormous number of people come daily - and this scenario suddenly becomes more realistic.
\n\nIn the given scenario, 5314:72:1:13:101 can actually be 19 different people. I am pretty sure that there are many more scenarios and some way more realistic than mine :)
", "rawMarkdown": "What I am saying is - it's not necessarily badly coded.I was trying to say the competition is badly designed if multiple downloads get multiple rewards.\nYou can see that this particular combination ip==5314&ap==72&dv==1&os==13&ch==101 seems to be a single user, not multiple users on same IP.\nAnyway, thanks for confirming that the user behavior seems legitimate and app 72 is not fraud. No need to discuss further.
Conversely if we look at their behavior across apps, their download behavior varies hugely by app, and looks mostly legit. So is this a legit customer? But still why do they download app=72 16 times out of 19 views?
\n\n> tr[ip==5314&dv==1&os==13&ch==101, list( tot_dload=sum(dload), tot_clicks=.N, dloads_per_click=mean(dload)), by=ap] [order(dloads_per_click)]\n\n ap tot_dload tot_clicks dloads_per_click\n 1 0 17 0.000000000\n 4 0 29 0.000000000\n 66 0 13 0.000000000\n 118 0 1 0.000000000\n 155 0 1 0.000000000\n 7 3 1155 0.002597403\n 92 3 11 0.272727273\n 29 1 3 0.333333333\n 244 2 4 0.500000000\n 39 5 7 0.714285714\n 72 16 19 0.842105263\nOne of the potential 'legit' scenarios might be a shopping mall with free wi-fi and a promotion going on in it - something like \"download our app and win discount, etc... blah blah\"
", "votes": null, "replies": [] }, { "id": 318563, "author_name": "smcinerney", "author_url": "", "post_date": "04/24/2018 04:01:54", "content": "...perhaps... but it's [EDIT: the competition is badly designed] if downloading multiple (16) times gives you 16 rewards, instead of one per IMEI.
", "votes": null, "replies": [] }, { "id": 318661, "author_name": "konchar", "author_url": "", "post_date": "04/24/2018 08:23:13", "content": "What I am saying is - it's not necessarily badly coded.
\nMy viewpoint is that 5314:72:1:13:101 should not be observed as a single user. The info that Ip : App : Device : Os : Channel combination gives us is not 'narrow' enough to observe it as a single user.
For example - take 19 people in a shopping mall with shared wifi (same ip). They are coming out of mobile shop, where they just purchased the most sold Android phone in China, hypothetically Samsung S9 (same device), with the factory default Android version installed (same os). \nNow, let's say that the first thing they want to do when they exit a shop is to download some very popular app that they frequently used on their old phone. So, they do a search on a very popular Baidu search engine and click an ad in the results (channel), in order to download (for example) WeChat app (same app). Now, since we are talking about China, imagine this in a huge shopping mall in some of the huge Chinese cities, where enormous number of people come daily - and this scenario suddenly becomes more realistic.
\n\nIn the given scenario, 5314:72:1:13:101 can actually be 19 different people. I am pretty sure that there are many more scenarios and some way more realistic than mine :)
", "votes": null, "replies": [] }, { "id": 318718, "author_name": "smcinerney", "author_url": "", "post_date": "04/24/2018 10:19:41", "content": "I was trying to say the competition is badly designed if multiple downloads get multiple rewards.\nYou can see that this particular combination ip==5314&ap==72&dv==1&os==13&ch==101 seems to be a single user, not multiple users on same IP.\nAnyway, thanks for confirming that the user behavior seems legitimate and app 72 is not fraud. No need to discuss further.
\n\n\n... but are we supposed to treat the following sort of user as non-fraudulent?
\n
Thing is, this contest asks us to estimate probability of a click resulting in a download (is_attributed==1). \nFrom the contest description:
\n\n\n\n\nFor each click_id in the test set, you must predict a probability for the target is_attributed variable.
\n
Therefore, I wouldn't worry much about suspicious 1's, as long as your solution gives them high probability.
", "votes": null, "replies": [ { "id": 318562, "author_name": "smcinerney", "author_url": "", "post_date": "04/24/2018 04:00:45", "content": "Right. We conclude the user download propensity varies strongly by app. And is presumably heavily influenced by the app type. viz. their behavior for app==72 is not necessarily fraud.
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "317219": "Sorry for the basic question, but are we supposed to treat the following sort of user as non-fraudulent? They do download, but suspiciously too much. Do we just ignore that? (In my renamed fields, 'dload' -> 'is_attributed' etc.)\n\n > tr[ip==5314&ap==72&dv==1&os==13&ch==101, ]\n ip ap dv os ch ctime atime dload L\n 5314 72 1 13 101 2017-11-07 00:55:41 2017-11-07 06:45:56 1 1\n 5314 72 1 13 101 2017-11-07 02:15:54 2017-11-07 03:08:38 1 2\n 5314 72 1 13 101 2017-11-07 08:47:37 2017-11-07 09:09:14 1 3\n 5314 72 1 13 101 2017-11-07 10:50:08 2017-11-07 11:37:13 1 4\n 5314 72 1 13 101 2017-11-07 12:42:50", "317226": "Conversely if we look at their behavior across apps, their download behavior varies hugely by app, and looks mostly legit. So is this a legit customer? But still why do they download app=72 16 times out of 19 views?\n\n > tr[ip==5314&dv==1&os==13&ch==101, list( tot_dload=sum(dload), tot_clicks=.N, dloads_per_click=mean(dload)), by=ap] [order(dloads_per_click)]\n\n ap tot_dload tot_clicks dloads_per_click\n 1 0 17 0.000000000\n 4 0 29 0.000000000\n 66 0 13 0.000000000\n 118 0 1 0.000000000\n 155 0 1 0.000000000\n 7 3 1155 0.002597403\n 92 3 11 0.272727273\n 29 1 3 0.333333333\n 244 2 4 0.500000000\n 39 5 7 0.714285714\n 72 16 19 0.842105263", "317756": "> ... but are we supposed to treat the following sort of user as non-fraudulent? \n\nThing is, this contest asks us to estimate probability of a click resulting in a download (is_attributed==1). \nFrom the contest description:\n> For each click_id in the test set, you must predict a probability for the target is_attributed variable.\n\nTherefore, I wouldn't worry much about suspicious 1's, as long as your solution gives them high probability.", "317757": "One of the potential 'legit' scenarios might be a shopping mall with free wi-fi and a promotion going on in it - something like \"download our app and win discount, etc... blah blah\"", "318562": "Right. We conclude the user download propensity varies strongly by app. And is presumably heavily influenced by the app type. viz. their behavior for app==72 is not necessarily fraud.", "318563": "...perhaps... but it's [EDIT: the competition is badly designed] if downloading multiple (16) times gives you 16 rewards, instead of one per IMEI.", "318661": "What I am saying is - it's not necessarily badly coded.