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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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? > > > > > > > >
