I believe there is wrong labeling in geoNetwork infomation. But after some correction, it can help cv at session level while it worsens score on the LB. And it worse the score.
\n\nFor example for data[data['fullVisitorId']==str(1182594311076605554)], I am pretty sure the
\n\n\nCambridge Europe Northern Europe Ireland Massachusetts
\n
is mislabeled and should change to
\n\n\n\n\nCambridge Americas Northern America United States Massachusetts
\n
and there are plenty of these in the whole dataset.
\n\nOr another example, data[data['geoNetwork.city']=='Arlington']there is city using same name while they are actually different.
\n\n\nArlington Americas Northern America United States Virginia
\n
and
\n\n\n\n\nArlington Americas Northern America United States Texas
\n
where I there they should be differentiated by adding prefix or something.
\n\nI just can't understand why it almost always lowered my performance. I believe this brings up the accuracy of the dataset and should help the model.
\n\nWhat I did wrong here or in the thinking or can I have some people who spent same time here discuss? Or this is discussed and can i get a link? Thanks in advance
", "messages": [ { "id": "401394", "postDate": "10/10/2018 02:24:03", "content": "I believe there is wrong labeling in geoNetwork infomation. But after some correction, it can help cv at session level while it worsens score on the LB. And it worse the score.
\n\nFor example for data[data['fullVisitorId']==str(1182594311076605554)], I am pretty sure the
\n\n\nCambridge Europe Northern Europe Ireland Massachusetts
\n
is mislabeled and should change to
\n\n\n\n\nCambridge Americas Northern America United States Massachusetts
\n
and there are plenty of these in the whole dataset.
\n\nOr another example, data[data['geoNetwork.city']=='Arlington']there is city using same name while they are actually different.
\n\n\nArlington Americas Northern America United States Virginia
\n
and
\n\n\n\n\nArlington Americas Northern America United States Texas
\n
where I there they should be differentiated by adding prefix or something.
\n\nI just can't understand why it almost always lowered my performance. I believe this brings up the accuracy of the dataset and should help the model.
\n\nWhat I did wrong here or in the thinking or can I have some people who spent same time here discuss? Or this is discussed and can i get a link? Thanks in advance
", "rawMarkdown": "I believe there is wrong labeling in geoNetwork infomation. But after some correction, it can help cv at session level while it worsens score on the LB. And it worse the score. \n\nFor example for `data[data['fullVisitorId']==str(1182594311076605554)]`, I am pretty sure the \n\n> Cambridge\tEurope\tNorthern Europe\tIreland\tMassachusetts\n\nis mislabeled and should change to\n>Cambridge\tAmericas\tNorthern America\tUnited States\tMassachusetts\n\nand there are plenty of these in the whole dataset.\n\nOr another example, `data[data['geoNetwork.city']=='Arlington']`there is city using same name while they are actually different.\n>Arlington\tAmericas\tNorthern America\tUnited States\tVirginia\n\nand\n\n>Arlington\tAmericas\tNorthern America\tUnited States\tTexas\n\nwhere I there they should be differentiated by adding prefix or something.\n\nI just can't understand why it almost always lowered my performance. I believe this brings up the accuracy of the dataset and should help the model.\n\nWhat I did wrong here or in the thinking or can I have some people who spent same time here discuss? Or this is discussed and can i get a link? Thanks in advance", "votes": null }, { "id": "401433", "postDate": "10/10/2018 04:33:50", "content": "You are right, there are a lot of mislabeling.
\n\nMy guess: a lot of mislabels are US city mislabeled to others country, which lower their scores. In the public LB, lower revenue prediction is somewhat helpful?
", "rawMarkdown": "You are right, there are a lot of mislabeling.\n\nMy guess: a lot of mislabels are US city mislabeled to others country, which lower their scores. In the public LB, lower revenue prediction is somewhat helpful?", "votes": null }, { "id": "401474", "postDate": "10/10/2018 06:18:48", "content": "I have explored this issue in my kernel. Basically, (country, subcontinent, continent) and (city, metro, region) are two groups that almost always agree with each other within the group itself, but there can be conflicts between groups. My guess is that the city level data probably comes from some form of device geo tracking whereas the country level data always agrees with \"domain\" (likely ISP), so it probably comes from IP address. I guess when people use proxy or when IP location is inaccurate, these two can be different, and a conflict occurs.\nAs for predictions, I still have not found a consistent distinction between fixing and not fixing the conflicts. Guess the number of affected rows is rather small compared to the whole set.
", "rawMarkdown": "I have explored this issue in my [kernel][1]. Basically, (country, subcontinent, continent) and (city, metro, region) are two groups that almost always agree with each other within the group itself, but there can be conflicts between groups. My guess is that the city level data probably comes from some form of device geo tracking whereas the country level data always agrees with \"domain\" (likely ISP), so it probably comes from IP address. I guess when people use proxy or when IP location is inaccurate, these two can be different, and a conflict occurs.\nAs for predictions, I still have not found a consistent distinction between fixing and not fixing the conflicts. Guess the number of affected rows is rather small compared to the whole set.\n\n\n [1]: https://www.kaggle.com/mithrillion/fixing-conflicts-in-the-geonetwork-attributes", "votes": null }, { "id": "401953", "postDate": "10/10/2018 23:35:12", "content": "Similar discussion is here.
\n\nI also spent some time on this topic, but, for now, I didn't find any useful insights except one thing as Mithrillion said: There are two groups on geoNetwork, which are [continent, subContinent, country, networkDomain] and [region, city, metro].
", "rawMarkdown": "Similar discussion is [here](https://www.kaggle.com/c/ga-customer-revenue-prediction/discussion/66627).\n\nI also spent some time on this topic, but, for now, I didn't find any useful insights except one thing as Mithrillion said: There are two groups on geoNetwork, which are [continent, subContinent, country, networkDomain] and [region, city, metro].", "votes": null } ], "comments": [ { "id": 401433, "author_name": "echowuhao", "author_url": "", "post_date": "10/10/2018 04:33:50", "content": "You are right, there are a lot of mislabeling.
\n\nMy guess: a lot of mislabels are US city mislabeled to others country, which lower their scores. In the public LB, lower revenue prediction is somewhat helpful?
", "votes": null, "replies": [] }, { "id": 401474, "author_name": "mithrillion", "author_url": "", "post_date": "10/10/2018 06:18:48", "content": "I have explored this issue in my kernel. Basically, (country, subcontinent, continent) and (city, metro, region) are two groups that almost always agree with each other within the group itself, but there can be conflicts between groups. My guess is that the city level data probably comes from some form of device geo tracking whereas the country level data always agrees with \"domain\" (likely ISP), so it probably comes from IP address. I guess when people use proxy or when IP location is inaccurate, these two can be different, and a conflict occurs.\nAs for predictions, I still have not found a consistent distinction between fixing and not fixing the conflicts. Guess the number of affected rows is rather small compared to the whole set.
", "votes": null, "replies": [] }, { "id": 401953, "author_name": "takaishikawa", "author_url": "", "post_date": "10/10/2018 23:35:12", "content": "Similar discussion is here.
\n\nI also spent some time on this topic, but, for now, I didn't find any useful insights except one thing as Mithrillion said: There are two groups on geoNetwork, which are [continent, subContinent, country, networkDomain] and [region, city, metro].
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "401394": "I believe there is wrong labeling in geoNetwork infomation. But after some correction, it can help cv at session level while it worsens score on the LB. And it worse the score. \n\nFor example for `data[data['fullVisitorId']==str(1182594311076605554)]`, I am pretty sure the \n\n> Cambridge\tEurope\tNorthern Europe\tIreland\tMassachusetts\n\nis mislabeled and should change to\n>Cambridge\tAmericas\tNorthern America\tUnited States\tMassachusetts\n\nand there are plenty of these in the whole dataset.\n\nOr another example, `data[data['geoNetwork.city']=='Arlington']`there is city using same name while they are actually different.\n>Arlington\tAmericas\tNorthern America\tUnited States\tVirginia\n\nand\n\n>Arlington\tAmericas\tNorthern America\tUnited States\tTexas\n\nwhere I there they should be differentiated by adding prefix or something.\n\nI just can't understand why it almost always lowered my performance. I believe this brings up the accuracy of the dataset and should help the model.\n\nWhat I did wrong here or in the thinking or can I have some people who spent same time here discuss? Or this is discussed and can i get a link? Thanks in advance", "401433": "You are right, there are a lot of mislabeling.\n\nMy guess: a lot of mislabels are US city mislabeled to others country, which lower their scores. In the public LB, lower revenue prediction is somewhat helpful?", "401474": "I have explored this issue in my [kernel][1]. Basically, (country, subcontinent, continent) and (city, metro, region) are two groups that almost always agree with each other within the group itself, but there can be conflicts between groups. My guess is that the city level data probably comes from some form of device geo tracking whereas the country level data always agrees with \"domain\" (likely ISP), so it probably comes from IP address. I guess when people use proxy or when IP location is inaccurate, these two can be different, and a conflict occurs.\nAs for predictions, I still have not found a consistent distinction between fixing and not fixing the conflicts. Guess the number of affected rows is rather small compared to the whole set.\n\n\n [1]: https://www.kaggle.com/mithrillion/fixing-conflicts-in-the-geonetwork-attributes", "401953": "Similar discussion is [here](https://www.kaggle.com/c/ga-customer-revenue-prediction/discussion/66627).\n\nI also spent some time on this topic, but, for now, I didn't find any useful insights except one thing as Mithrillion said: There are two groups on geoNetwork, which are [continent, subContinent, country, networkDomain] and [region, city, metro]." }, "source": "meta" }