\n\n\nattributed_time: if user download the app for after clicking an ad, this is the time of the app download
\n
Is attributed_time :\n1. Timestamp of when the downloading of the app finishes? or\n2. Timestamp of when the download button was clicked?
", "messages": [ { "id": "292872", "postDate": "03/08/2018 20:16:28", "content": "\n\n\nattributed_time: if user download the app for after clicking an ad, this is the time of the app download
\n
Is attributed_time :\n1. Timestamp of when the downloading of the app finishes? or\n2. Timestamp of when the download button was clicked?
", "rawMarkdown": "> \nattributed_time: if user download the app for after clicking an ad, this is the time of the app download\n\nIs attributed_time :\n1. Timestamp of when the downloading of the app finishes? or\n2. Timestamp of when the download button was clicked?", "votes": null }, { "id": "292986", "postDate": "03/09/2018 01:25:49", "content": "Good question. I believe it is option 1. Timestamp when the downloading of the app finishes. This is because complete download of the app in my mind would be considered as a download.\n Otherwise, one could click on download and then cancel before the download could complete.
", "rawMarkdown": "Good question. I believe it is option 1. Timestamp when the downloading of the app finishes. This is because complete download of the app in my mind would be considered as a download.\n Otherwise, one could click on download and then cancel before the download could complete.", "votes": null }, { "id": "293007", "postDate": "03/09/2018 02:50:48", "content": "Some of the attributed_times are almost immediately after the click time and don't seem to leave enough time for the download to happen. (See this kernel and the comments thereto.) So that would suggest it is #2. It's also possible that the times don't have a single, consistent meaning.
", "rawMarkdown": "Some of the attributed_times are almost immediately after the click time and don't seem to leave enough time for the download to happen. (See [this kernel][1] and the comments thereto.) So that would suggest it is #2. It's also possible that the times don't have a single, consistent meaning.\n\n [1]: https://www.kaggle.com/yuliagm/talkingdata-eda-plus-time-patterns", "votes": null }, { "id": "293090", "postDate": "03/09/2018 06:28:32", "content": "The attributed time is actually the install record upload time from SDK in the installed app.
\nAfter user install the app, SDK will be activated, and it will upload a record to server.
\nAs for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time.
\nShould have included it in data description, sorry for inconvenience.
\n\n\nAs for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time.
\n
The duration between click and attributed time seems to vary from 2 Secs to around 13 hrs in the sample data. Why does it ranges to so many hrs? Does it really take so much time or are these error entries?
", "rawMarkdown": "> As for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time. \n\nThe duration between click and attributed time seems to vary from 2 Secs to around 13 hrs in the sample data. Why does it ranges to so many hrs? Does it really take so much time or are these error entries?", "votes": null }, { "id": "293158", "postDate": "03/09/2018 09:41:06", "content": "The matching algorithm will have a maximum time range, like 24 hours. \nAs long as an install event can match a click event which has click_time <= install_time - 24hours, then we say the click is attributed.
\nYou can also check the answer.
Good question. I also believe it is #2. In any case I doubt I will even put this feature in my model... Perhaps somebody can explain how would this influence if one has decided to convert or not on first place?
", "rawMarkdown": "Good question. I also believe it is #2. In any case I doubt I will even put this feature in my model... Perhaps somebody can explain how would this influence if one has decided to convert or not on first place?", "votes": null }, { "id": "294649", "postDate": "03/12/2018 11:04:39", "content": "Considering that attributed_time is not included in test dataset and it has mostly null values, I think it will be better to leave it out of the dataset. It might be useful for exploration and checking behaviour of download after a click, but won't be very important for this competition.
\n\nIs there any way in which we can use it in our models ?
", "rawMarkdown": "Considering that attributed_time is not included in test dataset and it has mostly null values, I think it will be better to leave it out of the dataset. It might be useful for exploration and checking behaviour of download after a click, but won't be very important for this competition.\n\nIs there any way in which we can use it in our models ?", "votes": null }, { "id": "294704", "postDate": "03/12/2018 13:13:28", "content": "You can try predicting attributed time and using the prediction as a feature.
", "rawMarkdown": "You can try predicting attributed time and using the prediction as a feature.", "votes": null }, { "id": "295186", "postDate": "03/13/2018 07:58:07", "content": "To me it sounds way easier to predict if there will be attribution or not at first place compared to how long after the click an attribution will occur (if ever). I imagine it as the following problem - predict if a given person will drink a beer this evening. Do I understand correctly that you want to first predict how long it will take him to drink the beer and use this as a feature to predict if he is going to drink a beer or not? \nI guess I am missing something here, would be happy to be proven wrong...
", "rawMarkdown": "To me it sounds way easier to predict if there will be attribution or not at first place compared to how long after the click an attribution will occur (if ever). I imagine it as the following problem - predict if a given person will drink a beer this evening. Do I understand correctly that you want to first predict how long it will take him to drink the beer and use this as a feature to predict if he is going to drink a beer or not? \nI guess I am missing something here, would be happy to be proven wrong...", "votes": null }, { "id": "295323", "postDate": "03/13/2018 13:41:05", "content": "It's just a way of imposing some structure on the data. Suppose more careful people are less likely to drink beer and also drink it more slowly when they do. Maybe from fitting \"drink or not,\" your model doesn't happen to pick up the set of features that predict carefulness. Maybe when you fit \"how long to drink\" it does happen to pick up that set of features, because now it has more information to help distinguish what features relate to carefulness (since all the beer drinkers were previously in the same category, so, among them, it couldn't previously distinguish which ones were more careful). It's just something one could try.
", "rawMarkdown": "It's just a way of imposing some structure on the data. Suppose more careful people are less likely to drink beer and also drink it more slowly when they do. Maybe from fitting \"drink or not,\" your model doesn't happen to pick up the set of features that predict carefulness. Maybe when you fit \"how long to drink\" it does happen to pick up that set of features, because now it has more information to help distinguish what features relate to carefulness (since all the beer drinkers were previously in the same category, so, among them, it couldn't previously distinguish which ones were more careful). It's just something one could try.", "votes": null }, { "id": "295325", "postDate": "03/13/2018 13:46:02", "content": "Ok, now I get what you've meant. Thanks!
", "rawMarkdown": "Ok, now I get what you've meant. Thanks!", "votes": null } ], "comments": [ { "id": 292986, "author_name": "pranayk", "author_url": "", "post_date": "03/09/2018 01:25:49", "content": "Good question. I believe it is option 1. Timestamp when the downloading of the app finishes. This is because complete download of the app in my mind would be considered as a download.\n Otherwise, one could click on download and then cancel before the download could complete.
", "votes": null, "replies": [] }, { "id": 293007, "author_name": "aharless", "author_url": "", "post_date": "03/09/2018 02:50:48", "content": "Some of the attributed_times are almost immediately after the click time and don't seem to leave enough time for the download to happen. (See this kernel and the comments thereto.) So that would suggest it is #2. It's also possible that the times don't have a single, consistent meaning.
", "votes": null, "replies": [] }, { "id": 293090, "author_name": "aaronyin", "author_url": "", "post_date": "03/09/2018 06:28:32", "content": "The attributed time is actually the install record upload time from SDK in the installed app.
\nAfter user install the app, SDK will be activated, and it will upload a record to server.
\nAs for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time.
\nShould have included it in data description, sorry for inconvenience.
\n\n\nAs for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time.
\n
The duration between click and attributed time seems to vary from 2 Secs to around 13 hrs in the sample data. Why does it ranges to so many hrs? Does it really take so much time or are these error entries?
", "votes": null, "replies": [] }, { "id": 293158, "author_name": "aaronyin", "author_url": "", "post_date": "03/09/2018 09:41:06", "content": "The matching algorithm will have a maximum time range, like 24 hours. \nAs long as an install event can match a click event which has click_time <= install_time - 24hours, then we say the click is attributed.
\nYou can also check the answer.
Good question. I also believe it is #2. In any case I doubt I will even put this feature in my model... Perhaps somebody can explain how would this influence if one has decided to convert or not on first place?
", "votes": null, "replies": [] }, { "id": 294649, "author_name": "", "author_url": "", "post_date": "03/12/2018 11:04:39", "content": "Considering that attributed_time is not included in test dataset and it has mostly null values, I think it will be better to leave it out of the dataset. It might be useful for exploration and checking behaviour of download after a click, but won't be very important for this competition.
\n\nIs there any way in which we can use it in our models ?
", "votes": null, "replies": [ { "id": 294704, "author_name": "aharless", "author_url": "", "post_date": "03/12/2018 13:13:28", "content": "You can try predicting attributed time and using the prediction as a feature.
", "votes": null, "replies": [] }, { "id": 295186, "author_name": "asparuhhristov", "author_url": "", "post_date": "03/13/2018 07:58:07", "content": "To me it sounds way easier to predict if there will be attribution or not at first place compared to how long after the click an attribution will occur (if ever). I imagine it as the following problem - predict if a given person will drink a beer this evening. Do I understand correctly that you want to first predict how long it will take him to drink the beer and use this as a feature to predict if he is going to drink a beer or not? \nI guess I am missing something here, would be happy to be proven wrong...
", "votes": null, "replies": [] }, { "id": 295323, "author_name": "aharless", "author_url": "", "post_date": "03/13/2018 13:41:05", "content": "It's just a way of imposing some structure on the data. Suppose more careful people are less likely to drink beer and also drink it more slowly when they do. Maybe from fitting \"drink or not,\" your model doesn't happen to pick up the set of features that predict carefulness. Maybe when you fit \"how long to drink\" it does happen to pick up that set of features, because now it has more information to help distinguish what features relate to carefulness (since all the beer drinkers were previously in the same category, so, among them, it couldn't previously distinguish which ones were more careful). It's just something one could try.
", "votes": null, "replies": [] }, { "id": 295325, "author_name": "asparuhhristov", "author_url": "", "post_date": "03/13/2018 13:46:02", "content": "Ok, now I get what you've meant. Thanks!
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "292872": "> \nattributed_time: if user download the app for after clicking an ad, this is the time of the app download\n\nIs attributed_time :\n1. Timestamp of when the downloading of the app finishes? or\n2. Timestamp of when the download button was clicked?", "292986": "Good question. I believe it is option 1. Timestamp when the downloading of the app finishes. This is because complete download of the app in my mind would be considered as a download.\n Otherwise, one could click on download and then cancel before the download could complete.", "293007": "Some of the attributed_times are almost immediately after the click time and don't seem to leave enough time for the download to happen. (See [this kernel][1] and the comments thereto.) So that would suggest it is #2. It's also possible that the times don't have a single, consistent meaning.\n\n [1]: https://www.kaggle.com/yuliagm/talkingdata-eda-plus-time-patterns", "293090": "The attributed time is actually the install record upload time from SDK in the installed app. \nAfter user install the app, SDK will be activated, and it will upload a record to server. \nAs for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time. \nShould have included it in data description, sorry for inconvenience.", "293125": "> As for why there are some wried records, the attributed click is matched by attribution algorithm, for a new install event A uploaded, the algorithm will search a click event B with the highest match score, so click event B will have a attributed_time equals to the new install event A's uploaded time. \n\nThe duration between click and attributed time seems to vary from 2 Secs to around 13 hrs in the sample data. Why does it ranges to so many hrs? Does it really take so much time or are these error entries?", "293158": "The matching algorithm will have a maximum time range, like 24 hours. \nAs long as an install event can match a click event which has click_time <= install_time - 24hours, then we say the click is attributed. \nYou can also check the [answer][1].\n\n\n [1]: https://www.kaggle.com/yuliagm/talkingdata-eda-plus-time-patterns/comments", "294085": "Good question. I also believe it is #2. In any case I doubt I will even put this feature in my model... Perhaps somebody can explain how would this influence if one has decided to convert or not on first place?", "294649": "Considering that attributed_time is not included in test dataset and it has mostly null values, I think it will be better to leave it out of the dataset. It might be useful for exploration and checking behaviour of download after a click, but won't be very important for this competition.\n\nIs there any way in which we can use it in our models ?", "294704": "You can try predicting attributed time and using the prediction as a feature.", "295186": "To me it sounds way easier to predict if there will be attribution or not at first place compared to how long after the click an attribution will occur (if ever). I imagine it as the following problem - predict if a given person will drink a beer this evening. Do I understand correctly that you want to first predict how long it will take him to drink the beer and use this as a feature to predict if he is going to drink a beer or not? \nI guess I am missing something here, would be happy to be proven wrong...", "295323": "It's just a way of imposing some structure on the data. Suppose more careful people are less likely to drink beer and also drink it more slowly when they do. Maybe from fitting \"drink or not,\" your model doesn't happen to pick up the set of features that predict carefulness. Maybe when you fit \"how long to drink\" it does happen to pick up that set of features, because now it has more information to help distinguish what features relate to carefulness (since all the beer drinkers were previously in the same category, so, among them, it couldn't previously distinguish which ones were more careful). It's just something one could try.", "295325": "Ok, now I get what you've meant. Thanks!" }, "source": "meta" }