Item-Set Recommender

[Pat Ferrel <pa...@occamsmachete.com>]

B = all item-sets gathered from user actions, actions like purchased-together/shopping cart purchases, watchlists etc.
i = an item-set vector for a specific user

B:
itemSetID, items
1, iPad:iPad-case,stylus
2, iPad:battery-booster:iPad-case
 
[B’B]i = r_i, right?

[B’B] would be an item-item cooccurrence similarity matrix taken from item-set actions, calculated using LLR. The items-set IDs are not needed anymore.

This would imply that we could create an item-set indicator matrix, then use a user’s item-set as the query to get back an ordered list taken from cooccurrences in other items sets, rather than preference cooccurrences.

So instead of summing similar items to each separate item in a shopping cart to get an ordering of items to recommend (the way some people do shopping cart recs) we could use the cooccurrence recommender to get these directly from the items-sets. If the item-set is generated in near realtime we’d need Solr (or some search engine) for the queries.

The intuition being that things purchased together at the same time will give you better shopping cart recs than using user preferences generally. The item-sets often have something in common that user history will not lead you to. I suppose you’d have to have a good size chunk of items-sets to make it work.

Does this make sense?

Re: Shopping cart Recommender (was Item-set Recommender)

[Ted Dunning <te...@gmail.com>]

Yeah... this Amazon hack is just a way to do multi-modal recommendations
without actually having a framework capable of multi-modal operation.  It
is similar to taking a rating as equivalent to a fraction of a purchase.
 Neither has great standing and neither is necessary if you segregate the
action streams and use multi-modal methods.



On Sun, Apr 27, 2014 at 4:58 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:

> The literature has examples of building rules from item-sets, which seems
> pretty archaic. Also Amazon did a paper (2003?) on using individual items
> from the user’s cart then getting similar items and summing the weights to
> get ordering. Also seems wrong since the actions/user intent doesn’t really
> match. Notice that the method below does not make use of the userID, it is
> specific to an item-set ID so the user intent is narrowed. In other words
> it is not measuring taste (a long lived user trait)
>
> Was wondering if anyone has used the method below. I don’t have data for
> shopping carts at the present. The last time I did, we used the Amazon
> method but it always seemed wrong. The one good thing about it is you have
> purchase data very early on but may not have enough shopping carts for some
> time and if you don’t have enough traffic you may never get timely enough
> carts to make this work. In other words the catalog may turn over too
> quickly.
>
>
> On Apr 27, 2014, at 3:37 AM, Ted Dunning <te...@gmail.com> wrote:
>
> In general, any action that can be detected in a user history can be an
> item (column) in the user history matrix.  If you find that there are
> item-sets that seem to occur together, then appearance of the entire
> item-set can be a reasonable feature to be assigned a column.  Somewhat
> more plausible is that you start to offer small packages of multiple items
> in a single order and you count browsing, interacting and buying these
> packages as different actions to be recorded.
>
> The general rule of thumb is that anything is a reasonable behavior to
> analyze if it is plausible of evidence about the users state of mind vis a
> vis the potential recommended actions.  Plausible initially means that a
> kinda sorta domain expert suggests the connection.  Plausible later means
> that the feature gets picked up as an indicator for some recommendations.
> If it never gets picked up, then it clearly isn't serving as a competitive
> piece of evidence about user intent.
>
>
>
>
> On Sat, Apr 26, 2014 at 6:46 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> > B = all item-sets gathered from user actions, actions like
> > purchased-together/shopping cart purchases, watchlists etc.
> > i = an item-set vector for a specific user
> >
> > B:
> > itemSetID, items
> > 1, iPad:iPad-case,stylus
> > 2, iPad:battery-booster:iPad-case
> >
> > [B’B]i = r_i, right?
> >
> > [B’B] would be an item-item cooccurrence similarity matrix taken from
> > item-set actions, calculated using LLR. The items-set IDs are not needed
> > anymore.
> >
> > This would imply that we could create an item-set indicator matrix, then
> > use a user’s item-set as the query to get back an ordered list taken from
> > cooccurrences in other items sets, rather than preference cooccurrences.
> >
> > So instead of summing similar items to each separate item in a shopping
> > cart to get an ordering of items to recommend (the way some people do
> > shopping cart recs) we could use the cooccurrence recommender to get
> these
> > directly from the items-sets. If the item-set is generated in near
> realtime
> > we’d need Solr (or some search engine) for the queries.
> >
> > The intuition being that things purchased together at the same time will
> > give you better shopping cart recs than using user preferences generally.
> > The item-sets often have something in common that user history will not
> > lead you to. I suppose you’d have to have a good size chunk of items-sets
> > to make it work.
> >
> > Does this make sense?
> >
> >
> >
>
>

Shopping cart Recommender (was Item-set Recommender)

[Pat Ferrel <pa...@occamsmachete.com>]

The literature has examples of building rules from item-sets, which seems pretty archaic. Also Amazon did a paper (2003?) on using individual items from the user’s cart then getting similar items and summing the weights to get ordering. Also seems wrong since the actions/user intent doesn’t really match. Notice that the method below does not make use of the userID, it is specific to an item-set ID so the user intent is narrowed. In other words it is not measuring taste (a long lived user trait)

Was wondering if anyone has used the method below. I don’t have data for shopping carts at the present. The last time I did, we used the Amazon method but it always seemed wrong. The one good thing about it is you have purchase data very early on but may not have enough shopping carts for some time and if you don’t have enough traffic you may never get timely enough carts to make this work. In other words the catalog may turn over too quickly.


On Apr 27, 2014, at 3:37 AM, Ted Dunning <te...@gmail.com> wrote:

In general, any action that can be detected in a user history can be an
item (column) in the user history matrix.  If you find that there are
item-sets that seem to occur together, then appearance of the entire
item-set can be a reasonable feature to be assigned a column.  Somewhat
more plausible is that you start to offer small packages of multiple items
in a single order and you count browsing, interacting and buying these
packages as different actions to be recorded.

The general rule of thumb is that anything is a reasonable behavior to
analyze if it is plausible of evidence about the users state of mind vis a
vis the potential recommended actions.  Plausible initially means that a
kinda sorta domain expert suggests the connection.  Plausible later means
that the feature gets picked up as an indicator for some recommendations.
If it never gets picked up, then it clearly isn't serving as a competitive
piece of evidence about user intent.




On Sat, Apr 26, 2014 at 6:46 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:

> B = all item-sets gathered from user actions, actions like
> purchased-together/shopping cart purchases, watchlists etc.
> i = an item-set vector for a specific user
> 
> B:
> itemSetID, items
> 1, iPad:iPad-case,stylus
> 2, iPad:battery-booster:iPad-case
> 
> [B’B]i = r_i, right?
> 
> [B’B] would be an item-item cooccurrence similarity matrix taken from
> item-set actions, calculated using LLR. The items-set IDs are not needed
> anymore.
> 
> This would imply that we could create an item-set indicator matrix, then
> use a user’s item-set as the query to get back an ordered list taken from
> cooccurrences in other items sets, rather than preference cooccurrences.
> 
> So instead of summing similar items to each separate item in a shopping
> cart to get an ordering of items to recommend (the way some people do
> shopping cart recs) we could use the cooccurrence recommender to get these
> directly from the items-sets. If the item-set is generated in near realtime
> we’d need Solr (or some search engine) for the queries.
> 
> The intuition being that things purchased together at the same time will
> give you better shopping cart recs than using user preferences generally.
> The item-sets often have something in common that user history will not
> lead you to. I suppose you’d have to have a good size chunk of items-sets
> to make it work.
> 
> Does this make sense?
> 
> 
> 

Re: Item-Set Recommender

[Ted Dunning <te...@gmail.com>]

In general, any action that can be detected in a user history can be an
item (column) in the user history matrix.  If you find that there are
item-sets that seem to occur together, then appearance of the entire
item-set can be a reasonable feature to be assigned a column.  Somewhat
more plausible is that you start to offer small packages of multiple items
in a single order and you count browsing, interacting and buying these
packages as different actions to be recorded.

The general rule of thumb is that anything is a reasonable behavior to
analyze if it is plausible of evidence about the users state of mind vis a
vis the potential recommended actions.  Plausible initially means that a
kinda sorta domain expert suggests the connection.  Plausible later means
that the feature gets picked up as an indicator for some recommendations.
 If it never gets picked up, then it clearly isn't serving as a competitive
piece of evidence about user intent.




On Sat, Apr 26, 2014 at 6:46 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:

> B = all item-sets gathered from user actions, actions like
> purchased-together/shopping cart purchases, watchlists etc.
> i = an item-set vector for a specific user
>
> B:
> itemSetID, items
> 1, iPad:iPad-case,stylus
> 2, iPad:battery-booster:iPad-case
>
> [B’B]i = r_i, right?
>
> [B’B] would be an item-item cooccurrence similarity matrix taken from
> item-set actions, calculated using LLR. The items-set IDs are not needed
> anymore.
>
> This would imply that we could create an item-set indicator matrix, then
> use a user’s item-set as the query to get back an ordered list taken from
> cooccurrences in other items sets, rather than preference cooccurrences.
>
> So instead of summing similar items to each separate item in a shopping
> cart to get an ordering of items to recommend (the way some people do
> shopping cart recs) we could use the cooccurrence recommender to get these
> directly from the items-sets. If the item-set is generated in near realtime
> we’d need Solr (or some search engine) for the queries.
>
> The intuition being that things purchased together at the same time will
> give you better shopping cart recs than using user preferences generally.
> The item-sets often have something in common that user history will not
> lead you to. I suppose you’d have to have a good size chunk of items-sets
> to make it work.
>
> Does this make sense?
>
>
>