Association Scenario

Hi,

I have a product basket scenario in where I have to recommend contracts to a customer based on the product and the quantity he/she buys. Product Quantity is an important factor which administers the user in the purchase of a particular contract

I have the following tables with me.

Customer product transaction table, Customer Contract transaction tablebut there is no direct relationship between contract and product in the database. The only way the two can be linked is through the customer.

If I create a mining structure with Customer-Product information as the nested table and Customer-Contract information as the nested table with customer being the link between the two, the model is showing some irreverent contract recommendations.

what is the solution for the above problem? Is it because the is no direct relationship between the product and the contract?

How can I overcome this problem?

You are on the right track - you have the two nested tables that you need. What you want to do is to make the Product nested table as Input and the Contract nested table as Predict Only. Also, you may want to try excluding the product quantity to see how that impacts results.

Another important factor is how you set parameters for the AR algorithm. Setting the MINIMUM_SUPPORT and MINIMUM_PROBABILITY parameters are crucial - try lowering them until you find interesting results.

|||

Hi,

I tried the above changes but there was not much difference in the results. It still gives irrelevant recommendations.

Can you tell me how differentare the following two mining structures

1. Customertable => CASE Table

Customer – Product table => NESTED Table

Customer – Contract table => NESTED Table

2. Customer – Product table => CASE table

Customer – Contract table => NESTED Table

|||I'm not an expert in association but i think that in the first case

you're bound to have three kind of information : contract 1 /contract 2

OR product1 / product 2 OR contract / product (in fact it depends on

the key of your nested tables but in any case you'll get

contact/product association).
In the second case you won't have product1/product2 association. and the contract/ product association will have a support of 1

I don't really catch your problem but if you want to make the second mining structure, you will have to add customerID to your tables product and contract. With some sql queries, you should be able to prepare correctly your data|||

In the first structure it is possible for a single customer to have many products. In the second structure, each customer can only have one product.

Using the first model you can make Product INPUT and Contract PREDICT ONLY and you are asking the question the right way.

When you say it gives "irrelevant recommendations" what do you mean exactly? It could be that only the "irrelevant" ones are supported by the data, or you need to tweak the parameters a bit more.

If you aren't seeing what you want, use the same structure to create a decision tree model. This way you can look at the trees that are generated to see if there are meaningful patterns in the data. By default you will have 255 inputs (e.g. products) and 255 outputs (e.g. contracts), but that should be enough to get you started, you can adjust those parameters as necessary to refine the models.

Also, just for a question, how many customers, products, and contracts are there?

Thx

-Jamie

|||

Hi Jamie,

In the database there are totally around 800 customers, 300 products and 9 contracts.

These contracts are grouped logically in to long term, short term (depending on the product quantity) and some are applicable to certain products only.

Data in my database may look like the following

Customer - Product

Customer

Product

Quantity

Date

C1

P1

X

Jan 2005

C1

P1

Y

Feb 2005

C1

P2

X

March 2005

Customer – Contract

Customer

Contract

Date

C1

Contract1

June 2005 (For P1 bought in Jan 2005 as above)

C1

Contract2

March 2005 (For P1 bought in Feb 2005 as above)

C1

Contract3

March 2005 (For P2 bought)

So the relevant combinations would be

P1 – Quantity X – Contract1 (long term contract due to quantity X)

P1 – Quantity Y – Contract2 (short term contract due to quantity Y)

P2 – Quantity X – Contract 3 (Contract for the product type P3)

The other combinations are irrelevant.

These combinations or groupings are high level understanding and are not reflected at the technical level.

Some of the mining model recommendations are

1 . For the purchase of P1 of Quantity X apart from recommending Contract1 it also lists Contract2 and Contract3( irrelevant).

2. For P2 it recommends both Contract3 and Contract1 (irrelevant).