|
|
You're in the
sql server data mining
group:Cross Selling and predicting quantity sold?
sql server data mining:
(or nested key). Also make it input if you want to use it that way. I would recommend creating one model to predict what's likely and another model to predict quantities though. For quantities, you are going to want to use Decision Trees - be sure to set your feature selection parameters (MAXIMUM_INPUT ... etc) or many things will be feature selected away. -- -Jamie MacLennan SQL Server Data Mining This posting is provided "AS IS" with no warranties, and confers no rights. PLEASE POST NEW QUESTIONS AT http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 [quoted text, click to view] <anonymous_user@sqlserverdatamining.com> wrote in message news:7923333e-64e9-49ce-a3c2-2297f7b38d25@msnews.microsoft.com... > I've done a lot of web research and read a book on analysis services but > still haven't found an example of how to develop a cross selling algorithm > that can predict not only what is sold, but how much is predicted to be > sold. > > For instance, > If I know customer A has bought 5 units of item 1, 10 units of item 2, and > 20 units of item 3, I may know there is a 50% chance they will also want > to but item 4. > > Is there any way to determine how much of item 4 they might buy? > > For instnace, say Item 4 is batteries and Item1 is a clock radio. We know > that if they buy one clock radio they are likley to buy 2 batteries, but > if they buy 2 clock radios they are likley to buy 4 batteries, not 2. In > each case, there is the same likleyhood that they buy at least some > batteries. > > If my data set looks like this (in my sales table) > Customer / Item / Quantity > > How do I design the data mining model to account for quantity? I tried > several approaches to this and can't seem to get it to work correctly when > taking quantity into account. > > The method I used takes the sale table and makes it a case table and > nested table, treats the Customer from the cast table as a key, and the > item from the nested table as a key, input, and predict. This is how the > books I've read explain how to create a cross selling model. I don't > understand how I make it take quantity of each item into account. > > Would it be better to do this in a 2nd mining model and not use it in the > cross selling model? > > Thanks > Tom >
I've done a lot of web research and read a book on analysis services but still haven't found an example of how to develop a cross selling algorithm that can predict not only what is sold, but how much is predicted to be sold.
For instance, If I know customer A has bought 5 units of item 1, 10 units of item 2, and 20 units of item 3, I may know there is a 50% chance they will also want to but item 4. Is there any way to determine how much of item 4 they might buy? For instnace, say Item 4 is batteries and Item1 is a clock radio. We know that if they buy one clock radio they are likley to buy 2 batteries, but if they buy 2 clock radios they are likley to buy 4 batteries, not 2. In each case, there is the same likleyhood that they buy at least some batteries. If my data set looks like this (in my sales table) Customer / Item / Quantity How do I design the data mining model to account for quantity? I tried several approaches to this and can't seem to get it to work correctly when taking quantity into account. The method I used takes the sale table and makes it a case table and nested table, treats the Customer from the cast table as a key, and the item from the nested table as a key, input, and predict. This is how the books I've read explain how to create a cross selling model. I don't understand how I make it take quantity of each item into account. Would it be better to do this in a 2nd mining model and not use it in the cross selling model? Thanks Tom
You're close, but you have a little ways to go yet.
First - MAXIMUM_INPUT_ATTRIBUTES sets the number of inputs that are considered by the algorithm, not how many can be in a single case. For example, if you use the default - 255 and you have 1000 products, only 255 of those products will be considered by the algorithm - the others won't have any impact. Next you have Item and Quantity as independent case level attributes. This means that you have _one_ quantity attribute for all products. What you likely meant to do is to have the quantity tied to the customer/item pair. You could create a composite key which is Customer/Item, however, you are still looking at a single Quantity measure for all products. What you want to do is to simply make the quantity attributes in the nested table predictable. For example, using DMX to describe the model, it would look like this: CREATE MINING MODEL QuantityPredict ( CustomerID LONG KEY, Products TABLE, ( Item TEXT KEY, Quantity LONG REGRESSOR PREDICT // Input and Predictable ) ) USING Microsoft_Decision_Trees(MAXIMUM_INPUT_ATTRIBUTES=0,MAXIMUM_OUTPUT_ATTRIBUTES=0) Then to get the quantity of a particular item you would issue a query like this: SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM QuantityPredict NATURAL PREDICTION JOIN (SELECT (SELECT 'Radio' AS Item, 1 AS Quantity) as Products) as t -- -Jamie MacLennan SQL Server Data Mining This posting is provided "AS IS" with no warranties, and confers no rights. PLEASE POST NEW QUESTIONS AT http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 [quoted text, click to view] <anonymous_user@sqlserverdatamining.com> wrote in message news:319c7157-d70b-4c0a-a4ef-6df0d00fdadf@msnews.microsoft.com... > Jamie, > > Thanks for the response. I am trying, as you suggested, to create a > second model which will predict the quantity of a particular item that > someone may purchase. I'm trying to do this with nested tables again, and > am coming up with the following model: > > Sales table is treated as both a nested and case table: > Case Table: > Customer = Key > Item = Input > Quantity = PredictOnly > Nested Table: > Item = Key, Input > Quantity = Input > > The predictions I'm getting don't seem to change based on the quantity of > items in the nested table. > > Is this the right way to answer the question? In the example I gave, the > business question would be: > > A customer currently has 2 clock radios in their basket. Our cross > selling model (seperate model) tells us that their is a high liklihood > they will want to buy batteries. How many batteries are they likely to > buy given that we know how many clock radios they've got in their basket? > > In this case I would run a prediction query which looks like: > > Select FLATTENED > T.[Item], > PredictHistogram([Quantity]) > FROM [Model] > NATURAL PREDICTION JOIN > ( SELECT > 'Batteries' as [Item], > ( SELECT 'Clock Radio' AS [Item], 2 as Quantity > ) AS [Basket]) > AS t > > What I would expect is for this to return that it expects 4 batteries to > be purchased, since I know people who buy clock radio's normally buy 2x as > many batteries as they do radios. > > Am I writing this query incorrectly, or is my model wrong, or both? I'm > fairly new to using nested tables in analysis. > > Maximum Inputs is defaulted to 255, so as long as I don't have more than > that many items in my basked none of them will be feature selected away, > right? > > Thanks, > Tom >> >> You need to make the quantity column predictable and not the nested table >> (or nested key). Also make it input if you want to use it that way. >> >> I would recommend creating one model to predict what's likely and another >> model to predict quantities though. For quantities, you are going to >> want >> to use Decision Trees - be sure to set your feature selection parameters >> (MAXIMUM_INPUT ... etc) or many things will be feature selected away. >> >> -- >> >> -Jamie MacLennan >> SQL Server Data Mining >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> PLEASE POST NEW QUESTIONS AT >> http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 >> <anonymous_user@sqlserverdatamining.com> wrote in message >> news:7923333e-64e9-49ce-a3c2-2297f7b38d25@msnews.microsoft.com... >> > I've done a lot of web research and read a book on analysis services >> > but >> > still haven't found an example of how to develop a cross selling >> > algorithm >> > that can predict not only what is sold, but how much is predicted to be >> > sold. >> > >> > For instance, >> > If I know customer A has bought 5 units of item 1, 10 units of item 2, >> > and >> > 20 units of item 3, I may know there is a 50% chance they will also >> > want >> > to but item 4. >> > >> > Is there any way to determine how much of item 4 they might buy? >> > >> > For instnace, say Item 4 is batteries and Item1 is a clock radio. We >> > know >> > that if they buy one clock radio they are likley to buy 2 batteries, >> > but >> > if they buy 2 clock radios they are likley to buy 4 batteries, not 2. >> > In >> > each case, there is the same likleyhood that they buy at least some >> > batteries. >> > >> > If my data set looks like this (in my sales table) >> > Customer / Item / Quantity >> > >> > How do I design the data mining model to account for quantity? I >> > tried >> > several approaches to this and can't seem to get it to work correctly >> > when >> > taking quantity into account. >> > >> > The method I used takes the sale table and makes it a case table and >> > nested table, treats the Customer from the cast table as a key, and the >> > item from the nested table as a key, input, and predict. This is how >> > the >> > books I've read explain how to create a cross selling model. I don't >> > understand how I make it take quantity of each item into account. >> > >> > Would it be better to do this in a 2nd mining model and not use it in >> > the >> > cross selling model? >> > >> > Thanks >> > Tom >> > >> >>
You would have to look at the resultant model - the data might not support
your hypothesis. Another thing to try is to play with the other parameters - especially complexity penalty. -- -Jamie MacLennan SQL Server Data Mining This posting is provided "AS IS" with no warranties, and confers no rights. PLEASE POST NEW QUESTIONS AT http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 [quoted text, click to view] <anonymous_user@sqlserverdatamining.com> wrote in message
news:20c953a0-a82e-4341-b0b2-cab660773dd2@msnews.microsoft.com... > That makees sense, thanks! > > I tried implementing as you suggested but these two DMX statements return > the same results to me. Notice in one I specify the customer has 1 radio > in their basket, adn in the next statement I specify the customer has > 1,000 radios in their basket. What I'd expect to see is that the number > of batteries they purchase should be 1,000x higher in the second example. > The result I get appears to be closer to the average number of batteries > that customers who purchase radios purchase, rather than varying based on > the number of radios purcahsed. > > > SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM > QuantityPredict > NATURAL PREDICTION JOIN > (SELECT (SELECT 'Radio' AS Item, 1 AS Quantity) as Products) as t > > SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM > QuantityPredict > NATURAL PREDICTION JOIN > (SELECT (SELECT 'Radio' AS Item, 1000 AS Quantity) as Products) as t > > > So, the quantity of the items in the basket (the ones in the nested table, > in this case the radio) do not appear to be affecting the quantity of each > additional item begin predicted, which is really what I need for it to do. > In this case I'd want the first statement to predict 2 batteries and the > second statement to predict 2,000 batteries. > > Any ideas on what I'm missing here? > > Thanks, > Tom > > >> >> You're close, but you have a little ways to go yet. >> >> First - MAXIMUM_INPUT_ATTRIBUTES sets the number of inputs that are >> considered by the algorithm, not how many can be in a single case. For >> example, if you use the default - 255 and you have 1000 products, only >> 255 >> of those products will be considered by the algorithm - the others won't >> have any impact. >> >> Next you have Item and Quantity as independent case level attributes. >> This >> means that you have _one_ quantity attribute for all products. What you >> likely meant to do is to have the quantity tied to the customer/item >> pair. >> You could create a composite key which is Customer/Item, however, you are >> still looking at a single Quantity measure for all products. >> >> What you want to do is to simply make the quantity attributes in the >> nested >> table predictable. For example, using DMX to describe the model, it >> would >> look like this: >> >> CREATE MINING MODEL QuantityPredict >> ( >> CustomerID LONG KEY, >> Products TABLE, >> ( >> Item TEXT KEY, >> Quantity LONG REGRESSOR PREDICT // Input and Predictable >> ) >> ) USING >> Microsoft_Decision_Trees(MAXIMUM_INPUT_ATTRIBUTES=0,MAXIMUM_OUTPUT_ATTRIBUTES=0) >> >> Then to get the quantity of a particular item you would issue a query >> like >> this: >> >> SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM >> QuantityPredict >> NATURAL PREDICTION JOIN >> (SELECT (SELECT 'Radio' AS Item, 1 AS Quantity) as Products) as t >> >> -- >> >> -Jamie MacLennan >> SQL Server Data Mining >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> PLEASE POST NEW QUESTIONS AT >> http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 >> <anonymous_user@sqlserverdatamining.com> wrote in message >> news:319c7157-d70b-4c0a-a4ef-6df0d00fdadf@msnews.microsoft.com... >> > Jamie, >> > >> > Thanks for the response. I am trying, as you suggested, to create a >> > second model which will predict the quantity of a particular item that >> > someone may purchase. I'm trying to do this with nested tables again, >> > and >> > am coming up with the following model: >> > >> > Sales table is treated as both a nested and case table: >> > Case Table: >> > Customer = Key >> > Item = Input >> > Quantity = PredictOnly >> > Nested Table: >> > Item = Key, Input >> > Quantity = Input >> > >> > The predictions I'm getting don't seem to change based on the quantity >> > of >> > items in the nested table. >> > >> > Is this the right way to answer the question? In the example I gave, >> > the >> > business question would be: >> > >> > A customer currently has 2 clock radios in their basket. Our cross >> > selling model (seperate model) tells us that their is a high liklihood >> > they will want to buy batteries. How many batteries are they likely >> > to >> > buy given that we know how many clock radios they've got in their >> > basket? >> > >> > In this case I would run a prediction query which looks like: >> > >> > Select FLATTENED >> > T.[Item], >> > PredictHistogram([Quantity]) >> > FROM [Model] >> > NATURAL PREDICTION JOIN >> > ( SELECT >> > 'Batteries' as [Item], >> > ( SELECT 'Clock Radio' AS [Item], 2 as Quantity >> > ) AS [Basket]) >> > AS t >> > >> > What I would expect is for this to return that it expects 4 batteries >> > to >> > be purchased, since I know people who buy clock radio's normally buy 2x >> > as >> > many batteries as they do radios. >> > >> > Am I writing this query incorrectly, or is my model wrong, or both? >> > I'm >> > fairly new to using nested tables in analysis. >> > >> > Maximum Inputs is defaulted to 255, so as long as I don't have more >> > than >> > that many items in my basked none of them will be feature selected >> > away, >> > right? >> > >> > Thanks, >> > Tom >> >> >> >> You need to make the quantity column predictable and not the nested >> >> table >> >> (or nested key). Also make it input if you want to use it that way. >> >> >> >> I would recommend creating one model to predict what's likely and >> >> another >> >> model to predict quantities though. For quantities, you are going to >> >> want >> >> to use Decision Trees - be sure to set your feature selection >> >> parameters >> >> (MAXIMUM_INPUT ... etc) or many things will be feature selected away. >> >> >> >> -- >> >> >> >> -Jamie MacLennan >> >> SQL Server Data Mining >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. >> >> PLEASE POST NEW QUESTIONS AT >> >> http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 >> >> <anonymous_user@sqlserverdatamining.com> wrote in message >> >> news:7923333e-64e9-49ce-a3c2-2297f7b38d25@msnews.microsoft.com...
Jamie,
Thanks for the response. I am trying, as you suggested, to create a second model which will predict the quantity of a particular item that someone may purchase. I'm trying to do this with nested tables again, and am coming up with the following model: Sales table is treated as both a nested and case table: Case Table: Customer = Key Item = Input Quantity = PredictOnly Nested Table: Item = Key, Input Quantity = Input The predictions I'm getting don't seem to change based on the quantity of items in the nested table. Is this the right way to answer the question? In the example I gave, the business question would be: A customer currently has 2 clock radios in their basket. Our cross selling model (seperate model) tells us that their is a high liklihood they will want to buy batteries. How many batteries are they likely to buy given that we know how many clock radios they've got in their basket? In this case I would run a prediction query which looks like: Select FLATTENED T.[Item], PredictHistogram([Quantity]) FROM [Model] NATURAL PREDICTION JOIN ( SELECT 'Batteries' as [Item], ( SELECT 'Clock Radio' AS [Item], 2 as Quantity ) AS [Basket]) AS t What I would expect is for this to return that it expects 4 batteries to be purchased, since I know people who buy clock radio's normally buy 2x as many batteries as they do radios. Am I writing this query incorrectly, or is my model wrong, or both? I'm fairly new to using nested tables in analysis. Maximum Inputs is defaulted to 255, so as long as I don't have more than that many items in my basked none of them will be feature selected away, right? Thanks, Tom [quoted text, click to view] >
> You need to make the quantity column predictable and not the nested table > (or nested key). Also make it input if you want to use it that way. > > I would recommend creating one model to predict what's likely and another > model to predict quantities though. For quantities, you are going to want > to use Decision Trees - be sure to set your feature selection parameters > (MAXIMUM_INPUT ... etc) or many things will be feature selected away. > > -- > > -Jamie MacLennan > SQL Server Data Mining > This posting is provided "AS IS" with no warranties, and confers no rights. > PLEASE POST NEW QUESTIONS AT > http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 > <anonymous_user@sqlserverdatamining.com> wrote in message > news:7923333e-64e9-49ce-a3c2-2297f7b38d25@msnews.microsoft.com... > > I've done a lot of web research and read a book on analysis services but > > still haven't found an example of how to develop a cross selling algorithm > > that can predict not only what is sold, but how much is predicted to be > > sold. > > > > For instance, > > If I know customer A has bought 5 units of item 1, 10 units of item 2, and > > 20 units of item 3, I may know there is a 50% chance they will also want > > to but item 4. > > > > Is there any way to determine how much of item 4 they might buy? > > > > For instnace, say Item 4 is batteries and Item1 is a clock radio. We know > > that if they buy one clock radio they are likley to buy 2 batteries, but > > if they buy 2 clock radios they are likley to buy 4 batteries, not 2. In > > each case, there is the same likleyhood that they buy at least some > > batteries. > > > > If my data set looks like this (in my sales table) > > Customer / Item / Quantity > > > > How do I design the data mining model to account for quantity? I tried > > several approaches to this and can't seem to get it to work correctly when > > taking quantity into account. > > > > The method I used takes the sale table and makes it a case table and > > nested table, treats the Customer from the cast table as a key, and the > > item from the nested table as a key, input, and predict. This is how the > > books I've read explain how to create a cross selling model. I don't > > understand how I make it take quantity of each item into account. > > > > Would it be better to do this in a 2nd mining model and not use it in the > > cross selling model? > > > > Thanks > > Tom > > >
That makees sense, thanks!
I tried implementing as you suggested but these two DMX statements return the same results to me. Notice in one I specify the customer has 1 radio in their basket, adn in the next statement I specify the customer has 1,000 radios in their basket. What I'd expect to see is that the number of batteries they purchase should be 1,000x higher in the second example. The result I get appears to be closer to the average number of batteries that customers who purchase radios purchase, rather than varying based on the number of radios purcahsed. SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM QuantityPredict NATURAL PREDICTION JOIN (SELECT (SELECT 'Radio' AS Item, 1 AS Quantity) as Products) as t SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM QuantityPredict NATURAL PREDICTION JOIN (SELECT (SELECT 'Radio' AS Item, 1000 AS Quantity) as Products) as t So, the quantity of the items in the basket (the ones in the nested table, in this case the radio) do not appear to be affecting the quantity of each additional item begin predicted, which is really what I need for it to do. In this case I'd want the first statement to predict 2 batteries and the second statement to predict 2,000 batteries. Any ideas on what I'm missing here? Thanks, Tom [quoted text, click to view] >
> You're close, but you have a little ways to go yet. > > First - MAXIMUM_INPUT_ATTRIBUTES sets the number of inputs that are > considered by the algorithm, not how many can be in a single case. For > example, if you use the default - 255 and you have 1000 products, only 255 > of those products will be considered by the algorithm - the others won't > have any impact. > > Next you have Item and Quantity as independent case level attributes. This > means that you have _one_ quantity attribute for all products. What you > likely meant to do is to have the quantity tied to the customer/item pair. > You could create a composite key which is Customer/Item, however, you are > still looking at a single Quantity measure for all products. > > What you want to do is to simply make the quantity attributes in the nested > table predictable. For example, using DMX to describe the model, it would > look like this: > > CREATE MINING MODEL QuantityPredict > ( > CustomerID LONG KEY, > Products TABLE, > ( > Item TEXT KEY, > Quantity LONG REGRESSOR PREDICT // Input and Predictable > ) > ) USING > Microsoft_Decision_Trees(MAXIMUM_INPUT_ATTRIBUTES=0,MAXIMUM_OUTPUT_ATTRIBUTES=0) > > Then to get the quantity of a particular item you would issue a query like > this: > > SELECT (SELECT * FROM Predict(Products) WHERE Item='Batteries') FROM > QuantityPredict > NATURAL PREDICTION JOIN > (SELECT (SELECT 'Radio' AS Item, 1 AS Quantity) as Products) as t > > -- > > -Jamie MacLennan > SQL Server Data Mining > This posting is provided "AS IS" with no warranties, and confers no rights. > PLEASE POST NEW QUESTIONS AT > http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 > <anonymous_user@sqlserverdatamining.com> wrote in message > news:319c7157-d70b-4c0a-a4ef-6df0d00fdadf@msnews.microsoft.com... > > Jamie, > > > > Thanks for the response. I am trying, as you suggested, to create a > > second model which will predict the quantity of a particular item that > > someone may purchase. I'm trying to do this with nested tables again, and > > am coming up with the following model: > > > > Sales table is treated as both a nested and case table: > > Case Table: > > Customer = Key > > Item = Input > > Quantity = PredictOnly > > Nested Table: > > Item = Key, Input > > Quantity = Input > > > > The predictions I'm getting don't seem to change based on the quantity of > > items in the nested table. > > > > Is this the right way to answer the question? In the example I gave, the > > business question would be: > > > > A customer currently has 2 clock radios in their basket. Our cross > > selling model (seperate model) tells us that their is a high liklihood > > they will want to buy batteries. How many batteries are they likely to > > buy given that we know how many clock radios they've got in their basket? > > > > In this case I would run a prediction query which looks like: > > > > Select FLATTENED > > T.[Item], > > PredictHistogram([Quantity]) > > FROM [Model] > > NATURAL PREDICTION JOIN > > ( SELECT > > 'Batteries' as [Item], > > ( SELECT 'Clock Radio' AS [Item], 2 as Quantity > > ) AS [Basket]) > > AS t > > > > What I would expect is for this to return that it expects 4 batteries to > > be purchased, since I know people who buy clock radio's normally buy 2x as > > many batteries as they do radios. > > > > Am I writing this query incorrectly, or is my model wrong, or both? I'm > > fairly new to using nested tables in analysis. > > > > Maximum Inputs is defaulted to 255, so as long as I don't have more than > > that many items in my basked none of them will be feature selected away, > > right? > > > > Thanks, > > Tom > >> > >> You need to make the quantity column predictable and not the nested table > >> (or nested key). Also make it input if you want to use it that way. > >> > >> I would recommend creating one model to predict what's likely and another > >> model to predict quantities though. For quantities, you are going to > >> want > >> to use Decision Trees - be sure to set your feature selection parameters > >> (MAXIMUM_INPUT ... etc) or many things will be feature selected away. > >> > >> -- > >> > >> -Jamie MacLennan > >> SQL Server Data Mining > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> PLEASE POST NEW QUESTIONS AT > >> http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 > >> <anonymous_user@sqlserverdatamining.com> wrote in message > >> news:7923333e-64e9-49ce-a3c2-2297f7b38d25@msnews.microsoft.com... > >> > I've done a lot of web research and read a book on analysis services > >> > but > >> > still haven't found an example of how to develop a cross selling > >> > algorithm > >> > that can predict not only what is sold, but how much is predicted to be > >> > sold. > >> > > >> > For instance, > >> > If I know customer A has bought 5 units of item 1, 10 units of item 2, > >> > and > >> > 20 units of item 3, I may know there is a 50% chance they will also > >> > want > >> > to but item 4. > >> > > >> > Is there any way to determine how much of item 4 they might buy? > >> > > >> > For instnace, say Item 4 is batteries and Item1 is a clock radio. We > >> > know > >> > that if they buy one clock radio they are likley to buy 2 batteries, > >> > but
As I said in my previous response, you need to look at the model that was
created - due to the data, there may not be any significant relationship. -- -Jamie MacLennan SQL Server Data Mining This posting is provided "AS IS" with no warranties, and confers no rights. PLEASE POST NEW QUESTIONS AT http://forums.microsoft.com/msdn/showforum.aspx?forumid=81&siteid=1 [quoted text, click to view] <anonymous_user@sqlserverdatamining.com> wrote in message news:735c78f0-8bf5-40d2-98c1-50a8098d11c7@msnews.microsoft.com... > This page does describe the method you suggestedI use, but I'm still > having a problem getting the quantity predicted to change based on the > quantity of other items purchased. My test data set is very small, could > that be causing the problem? Again, what I would expect is that if it's > predicting quantity then the predicted quantity should change based on the > quantity of other items purchased. But for my example, no matter how many > radios I put in the basked the quantity of batteries predicted stays the > same and the percent chance of purchasing batteries stays the same too. > > http://www.sqlserverdatamining.com/DMCommunity/TipsNTricks/1090.aspx > > Any ideas on why this is the case would be appreciated. > > Thanks, > Tom > > > >> >> I've done a lot of web research and read a book on analysis services but >> still haven't found an example of how to develop a cross selling >> algorithm that can predict not only what is sold, but how much is >> predicted to be sold. >> >> For instance, >> If I know customer A has bought 5 units of item 1, 10 units of item 2, >> and 20 units of item 3, I may know there is a 50% chance they will also >> want to but item 4. >> >> Is there any way to determine how much of item 4 they might buy? >> >> For instnace, say Item 4 is batteries and Item1 is a clock radio. We >> know that if they buy one clock radio they are likley to buy 2 batteries, >> but if they buy 2 clock radios they are likley to buy 4 batteries, not 2. >> In each case, there is the same likleyhood that they buy at least some >> batteries. >> >> If my data set looks like this (in my sales table) >> Customer / Item / Quantity >> >> How do I design the data mining model to account for quantity? I tried >> several approaches to this and can't seem to get it to work correctly >> when taking quantity into account. >> >> The method I used takes the sale table and makes it a case table and >> nested table, treats the Customer from the cast table as a key, and the >> item from the nested table as a key, input, and predict. This is how the >> books I've read explain how to create a cross selling model. I don't >> understand how I make it take quantity of each item into account. >> >> Would it be better to do this in a 2nd mining model and not use it in the >> cross selling model? >> >> Thanks >> Tom >>
This page does describe the method you suggestedI use, but I'm still having a problem getting the quantity predicted to change based on the quantity of other items purchased. My test data set is very small, could that be causing the problem? Again, what I would expect is that if it's predicting quantity then the predicted quantity should change based on the quantity of other items purchased. But for my example, no matter how many radios I put in the basked the quantity of batteries predicted stays the same and the percent chance of purchasing batteries stays the same too.
http://www.sqlserverdatamining.com/DMCommunity/TipsNTricks/1090.aspx Any ideas on why this is the case would be appreciated. Thanks, Tom [quoted text, click to view] >
> I've done a lot of web research and read a book on analysis services but still haven't found an example of how to develop a cross selling algorithm that can predict not only what is sold, but how much is predicted to be sold. > > For instance, > If I know customer A has bought 5 units of item 1, 10 units of item 2, and 20 units of item 3, I may know there is a 50% chance they will also want to but item 4. > > Is there any way to determine how much of item 4 they might buy? > > For instnace, say Item 4 is batteries and Item1 is a clock radio. We know that if they buy one clock radio they are likley to buy 2 batteries, but if they buy 2 clock radios they are likley to buy 4 batteries, not 2. In each case, there is the same likleyhood that they buy at least some batteries. > > If my data set looks like this (in my sales table) > Customer / Item / Quantity > > How do I design the data mining model to account for quantity? I tried several approaches to this and can't seem to get it to work correctly when taking quantity into account. > > The method I used takes the sale table and makes it a case table and nested table, treats the Customer from the cast table as a key, and the item from the nested table as a key, input, and predict. This is how the books I've read explain how to create a cross selling model. I don't understand how I make it take quantity of each item into account. > > Would it be better to do this in a 2nd mining model and not use it in the cross selling model? > > Thanks > Tom
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |