Hi all,
\n\nI'm not sure to understand the transactions.csv file.
\n\nIt seems that it is the financial transactions (number of time customers go to the checkout by date and store_nbr).\nBut the correlation with unit sales of the train dataset looks odd.
\n\n2 examples:
\n\n1) If I compare 2013-04-06 with 2017-04-08 (both are Saturday) :
\n\nunit_sales 509424.21875 \ntransactions 94844.00000 \nratio 5.37118 \nName: 2013-04-06 00:00:00, dtype: float64 \n\nunit_sales 988590.500000 \ntransactions 98033.000000 \nratio 10.084262 \nName: 2017-04-08 00:00:00, dtype: float64 \n\n\n
The count of transactions are quite the same but the count of unit_sales just doubles.\nDoes it mean that the average basket size doubles in 4 years?
\n\n2) Look at the first semester of 2015. The transactions seem to stay stable while the unit_sales drop roughly.
\n\nDid I miss something? (certainly ^^)
\nThanks for your help.
PS: I'll try to add a kernel with the plot of both unit_sales and transactions
", "messages": [ { "id": "236012", "postDate": "10/26/2017 14:11:23", "content": "Hi all,
\n\nI'm not sure to understand the transactions.csv file.
\n\nIt seems that it is the financial transactions (number of time customers go to the checkout by date and store_nbr).\nBut the correlation with unit sales of the train dataset looks odd.
\n\n2 examples:
\n\n1) If I compare 2013-04-06 with 2017-04-08 (both are Saturday) :
\n\nunit_sales 509424.21875 \ntransactions 94844.00000 \nratio 5.37118 \nName: 2013-04-06 00:00:00, dtype: float64 \n\nunit_sales 988590.500000 \ntransactions 98033.000000 \nratio 10.084262 \nName: 2017-04-08 00:00:00, dtype: float64 \n\n\n
The count of transactions are quite the same but the count of unit_sales just doubles.\nDoes it mean that the average basket size doubles in 4 years?
\n\n2) Look at the first semester of 2015. The transactions seem to stay stable while the unit_sales drop roughly.
\n\nDid I miss something? (certainly ^^)
\nThanks for your help.
PS: I'll try to add a kernel with the plot of both unit_sales and transactions
", "rawMarkdown": "Hi all,\n\nI'm not sure to understand the transactions.csv file.\n\nIt seems that it is the financial transactions (number of time customers go to the checkout by date and store_nbr).\nBut the correlation with unit sales of the train dataset looks odd.\n\n2 examples:\n\n1) If I compare 2013-04-06 with 2017-04-08 (both are Saturday) :\nunit_sales 509424.21875 \ntransactions 94844.00000 \nratio 5.37118 \nName: 2013-04-06 00:00:00, dtype: float64 \n\nunit_sales 988590.500000 \ntransactions 98033.000000 \nratio 10.084262 \nName: 2017-04-08 00:00:00, dtype: float64 \n\n\nThe count of transactions are quite the same but the count of unit_sales just doubles.\nDoes it mean that the average basket size doubles in 4 years?\n\n2) Look at the first semester of 2015. The transactions seem to stay stable while the unit_sales drop roughly.\n\nDid I miss something? (certainly ^^) \nThanks for your help.\n\nPS: I'll try to add a kernel with the plot of both unit_sales and transactions", "votes": null }, { "id": "236023", "postDate": "10/26/2017 14:34:27", "content": "
The kernel associated to this discussion: https://www.kaggle.com/ericdfr/transactions
", "rawMarkdown": "The kernel associated to this discussion: https://www.kaggle.com/ericdfr/transactions", "votes": null }, { "id": "236315", "postDate": "10/27/2017 04:11:17", "content": "For # 1, I think you need to be careful comparing data from two single days. The daily unit sales data are very volatile and its possible you are comparing a day with low unit sales to a day with high unit sales, hence the doubling of the ratio. You may want to smooth the data by looking at the change in sales/transactions ratio between two different weeks or months rather than days.
", "rawMarkdown": "For # 1, I think you need to be careful comparing data from two single days. The daily unit sales data are very volatile and its possible you are comparing a day with low unit sales to a day with high unit sales, hence the doubling of the ratio. You may want to smooth the data by looking at the change in sales/transactions ratio between two different weeks or months rather than days.", "votes": null }, { "id": "238690", "postDate": "11/01/2017 23:31:26", "content": "I am agreeing with your analysis. My first thought was to searching for an economic reason like changed consumer behavior, shrinked packed sizes, successful cross product marketing, but I don't think it neither can explain the doubled basket size and the (above) examples that came first to my mind would move the ratio to the other direction.
", "rawMarkdown": "I am agreeing with your analysis. My first thought was to searching for an economic reason like changed consumer behavior, shrinked packed sizes, successful cross product marketing, but I don't think it neither can explain the doubled basket size and the (above) examples that came first to my mind would move the ratio to the other direction.", "votes": null }, { "id": "239369", "postDate": "11/03/2017 09:34:20", "content": "Thanks for your reply. Nobody seems to be interested in the transactions data except you and me. :-)
\nUnless I understand the dataset, I won't use it in my model.
That's not true - I am very interested in transactions (like average value across a week etc), it's just that once you incorporate lagged values of the sales, lagged transactions don't carry that much additional info :-)
", "rawMarkdown": "That's not true - I am very interested in transactions (like average value across a week etc), it's just that once you incorporate lagged values of the sales, lagged transactions don't carry that much additional info :-)", "votes": null }, { "id": "240878", "postDate": "11/07/2017 15:05:24", "content": "Hi Konrad,
\nWhat do you mean by \"lagged values of sales\" and \"lagged transactions\"?\nThanks ! :-)
At each point in time, using some sort of aggregate for both (e.g. 'average sales two weeks ago' or 'average # transactions' three weeks ago). We need the lag to ensure features created in the training and test parts are comparable, and the average helps with the short term variations.
", "rawMarkdown": "At each point in time, using some sort of aggregate for both (e.g. 'average sales two weeks ago' or 'average # transactions' three weeks ago). We need the lag to ensure features created in the training and test parts are comparable, and the average helps with the short term variations.", "votes": null }, { "id": "243101", "postDate": "11/13/2017 11:09:30", "content": "Why is the number of transactions for a particular store/date combo in transactions.csv is not matching with the total number of store/date records in train.csv??
", "rawMarkdown": "Why is the number of transactions for a particular store/date combo in transactions.csv is not matching with the total number of store/date records in train.csv??", "votes": null }, { "id": "243104", "postDate": "11/13/2017 11:18:42", "content": "For me, it is the number of time customers go to the checkout.
\nSo I suppose that sum of train by store/date = sum of transactions by store/date * average basket size.
\nBut as I said the average basket size varies too much over time. :-/
Got it! Thanks!! :-)
", "rawMarkdown": "Got it! Thanks!! :-)", "votes": null } ], "comments": [ { "id": 236023, "author_name": "ericdfr", "author_url": "", "post_date": "10/26/2017 14:34:27", "content": "The kernel associated to this discussion: https://www.kaggle.com/ericdfr/transactions
", "votes": null, "replies": [] }, { "id": 236315, "author_name": "captcalculator", "author_url": "", "post_date": "10/27/2017 04:11:17", "content": "For # 1, I think you need to be careful comparing data from two single days. The daily unit sales data are very volatile and its possible you are comparing a day with low unit sales to a day with high unit sales, hence the doubling of the ratio. You may want to smooth the data by looking at the change in sales/transactions ratio between two different weeks or months rather than days.
", "votes": null, "replies": [] }, { "id": 238690, "author_name": "flygare", "author_url": "", "post_date": "11/01/2017 23:31:26", "content": "I am agreeing with your analysis. My first thought was to searching for an economic reason like changed consumer behavior, shrinked packed sizes, successful cross product marketing, but I don't think it neither can explain the doubled basket size and the (above) examples that came first to my mind would move the ratio to the other direction.
", "votes": null, "replies": [ { "id": 239369, "author_name": "ericdfr", "author_url": "", "post_date": "11/03/2017 09:34:20", "content": "Thanks for your reply. Nobody seems to be interested in the transactions data except you and me. :-)
\nUnless I understand the dataset, I won't use it in my model.
That's not true - I am very interested in transactions (like average value across a week etc), it's just that once you incorporate lagged values of the sales, lagged transactions don't carry that much additional info :-)
", "votes": null, "replies": [] }, { "id": 240878, "author_name": "ericdfr", "author_url": "", "post_date": "11/07/2017 15:05:24", "content": "Hi Konrad,
\nWhat do you mean by \"lagged values of sales\" and \"lagged transactions\"?\nThanks ! :-)
At each point in time, using some sort of aggregate for both (e.g. 'average sales two weeks ago' or 'average # transactions' three weeks ago). We need the lag to ensure features created in the training and test parts are comparable, and the average helps with the short term variations.
", "votes": null, "replies": [] }, { "id": 243105, "author_name": "ericdfr", "author_url": "", "post_date": "11/13/2017 11:19:16", "content": "Got it! Thanks!! :-)
", "votes": null, "replies": [] } ] }, { "id": 243101, "author_name": "jsprasad", "author_url": "", "post_date": "11/13/2017 11:09:30", "content": "Why is the number of transactions for a particular store/date combo in transactions.csv is not matching with the total number of store/date records in train.csv??
", "votes": null, "replies": [ { "id": 243104, "author_name": "ericdfr", "author_url": "", "post_date": "11/13/2017 11:18:42", "content": "For me, it is the number of time customers go to the checkout.
\nSo I suppose that sum of train by store/date = sum of transactions by store/date * average basket size.
\nBut as I said the average basket size varies too much over time. :-/
unit_sales 509424.21875 \ntransactions 94844.00000 \nratio 5.37118 \nName: 2013-04-06 00:00:00, dtype: float64 \n\nunit_sales 988590.500000 \ntransactions 98033.000000 \nratio 10.084262 \nName: 2017-04-08 00:00:00, dtype: float64 \n\n\nThe count of transactions are quite the same but the count of unit_sales just doubles.\nDoes it mean that the average basket size doubles in 4 years?\n\n2) Look at the first semester of 2015. The transactions seem to stay stable while the unit_sales drop roughly.\n\nDid I miss something? (certainly ^^) \nThanks for your help.\n\nPS: I'll try to add a kernel with the plot of both unit_sales and transactions", "236023": "The kernel associated to this discussion: https://www.kaggle.com/ericdfr/transactions", "236315": "For # 1, I think you need to be careful comparing data from two single days. The daily unit sales data are very volatile and its possible you are comparing a day with low unit sales to a day with high unit sales, hence the doubling of the ratio. You may want to smooth the data by looking at the change in sales/transactions ratio between two different weeks or months rather than days.", "238690": "I am agreeing with your analysis. My first thought was to searching for an economic reason like changed consumer behavior, shrinked packed sizes, successful cross product marketing, but I don't think it neither can explain the doubled basket size and the (above) examples that came first to my mind would move the ratio to the other direction.", "239369": "Thanks for your reply. Nobody seems to be interested in the transactions data except you and me. :-) \nUnless I understand the dataset, I won't use it in my model.", "239371": "That's not true - I am very interested in transactions (like average value across a week etc), it's just that once you incorporate lagged values of the sales, lagged transactions don't carry that much additional info :-)", "240878": "Hi Konrad, \nWhat do you mean by \"lagged values of sales\" and \"lagged transactions\"?\nThanks ! :-)", "240898": "At each point in time, using some sort of aggregate for both (e.g. 'average sales two weeks ago' or 'average # transactions' three weeks ago). We need the lag to ensure features created in the training and test parts are comparable, and the average helps with the short term variations.", "243101": "Why is the number of transactions for a particular store/date combo in transactions.csv is not matching with the total number of store/date records in train.csv??", "243104": "For me, it is the number of time customers go to the checkout. \nSo I suppose that `sum of train by store/date = sum of transactions by store/date * average basket size`. \nBut as I said the average basket size varies too much over time. :-/", "243105": "Got it! Thanks!! :-)" }, "source": "meta" }