proper usage of "location-pref"

[Simonluca Landi]

Hello!

We run an ecom that sells digital products all around the world.
Here is what we modeled so far.
We have 2 entities, "user" and "item".
The primary indicator that we are using is "buy",

{
        "event" : "buy",
        "entityType" : "user",
        "entityId" : "us...@example.com",
        "targetEntityId" : "DigitalProduct1",
        "eventTime" : ISODate("2023-06-09T08:59:16.512Z")
}

and for each "item" we record a "country_code" (ie: where the digital product can be used) and a "category"

{
  "event": "$set",
  "entityType": "item",
  "entityId": "DigitalProduct1",
  "properties": {
    "country_code": [
      "US"
    ],
    "category": [
      "e-commerce"
    ]
  },
  "eventTime": "2023-06-10T07:43:22.129649945Z"
}

As the country where the user is buying from is often different from the "country_code" of the item, we also record a "location-pref" indicator
{
  "event": "location-pref",
  "entityType": "user",
  "entityId": "us...@example.com",
  "targetEntityType": "item",
  "targetEntityId": "DE",
  "eventTime": "2023-06-10T07:40:46.501540121Z"
}

So, in this example us...@example.com purchased "DigitalProduct1" from country "DE".

As our ecom can be accessed from different client apps, (think web browser, Android app, ios app,...) we also record a "app-pref" indicator

{
  "event": "app-pref",
  "entityType": "user",
  "entityId": "us...@example.com",
  "targetEntityType": "item",
  "targetEntityId": "mobile-app",
  "eventTime": "2023-06-10T07:40:46.501540121Z"
}


The training model is like this:

 "algorithm":{
    "indicators": [
      {"name": "buy"},
      {"name": "location-pref", "maxCorrelatorsPerItem": 10},
      {"name": "app-pref", "maxCorrelatorsPerItem": 2}
    ],
    "maxEventsPerEventType": 500000,
    "maxCorrelatorsPerEventType":500,
    "blacklistIndicators": [],
    "rankings": [
      {
        "type": "popular",
        "duration": "90 days"
      }
    ]

  }
 
We trained the model with some real data, about 250k events and 1000 items.
 
Now the questions :)

1 - when a user lands on the homepage, the only thing we assume to know is the country (from the IP address), ie the "location-pref"
Here we already show to the users the "items" from our catalog according to the "country_code". IE: to a user from DE we show items with country_code:DE
But as i mentioned, users from a country often shop for items for a different country_code, so we want to recommend items using a query based on "location-pref",
also considering the "app-pref", something like:

"rules":[{"name":"location-pref", "values":["DE"], "bias":-1}, {"name":"app-pref", "values":["none"], "bias":-1}]

The result of this query is a bit strange, or let's say it's not want we want: it seams that the algorithm is just sorting the items by global popularity and filter them for "location-pref".
For example, items that are sold a lot all over the world, but that have been purchased from "DE" just a few times, are ranked top,
well before items that are top seller from "DE".

How to get the "top seller from DE" items ranking first?


2 - when a user is then logged in, we want to make some specific recommendation for him. As mostly of the users are returnig and buying the same few items,
we want to recommend the previous purchased items first, and then some other products the user can like.

We are using query like: "user": "us...@example.com", but again the results are not what we expected.  How to have the the previous purchased items ranked first?

Thank you.

[Pat Ferrel]

A bit of general advice: do not use tuning settings until you need to. They often do not work like you might assume until you understand a recommender well. Things like 

    "maxEventsPerEventType": 500000,
    "maxCorrelatorsPerEventType":500,
    "blacklistIndicators": [],

I’d remove those settings for now.

The return of items sorted for popularity means you have no effective recommendation model. Try removing all rules to see if results change. Filters can restrict what is returned so much that you will have not results, in which case popular items will be used as results on the theory that popular is better than nothing (this has been shown from tests).

I think you have the rule def wrong. Rules ONLY refer to item properties, you are using event names in rules. This effectively means that NO ITEMS will satisfy these rules. Only the properties you set with the $set can be used in rules.

I would interpret what you are saying below to mean: you know the app and location a userr is using to access your site. You would like to use this data to make an (admittedly weak) guess about recommendations. Ok then why use rules at all? If data encodes events for app-pref and location-pref there is no need to use rules to make recs to a user where app and location pref are known (if you are sending this data in real time as the user visits the site).

If you also want to give a boost to products from the same country as the user then use a boost rather than filter and use only the country_code or category since these seem to be the only properties for the items as seen in your $set.

Filters are better saved for times when you know you might be recommended some items that you don’t want the user to see. For instance a product that is “out of stock”. In this case make sure to $set all items with out_of_stock: “true” oor “false”. Then add the out_of_stock filter to the queries.

In all cases try without setting ANY setting that doesn’t require a value and do not use filters or boosts until you have tried without them. The UR comes with good default values for everything needed to do ecom, change these only once you have tried without them.

--
You received this message because you are subscribed to the Google Groups "actionml-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to actionml-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/actionml-user/c5ae4e87-2671-4509-9225-9d29f36567f9n%40googlegroups.com.

[Simonluca Landi]

Thank you for the clarification about how the rules work: it was not clear to me that rules work ONLY only item properties. 

I just read again the doc about "user":

• user: optional, contains a unique id for the user. This may be a user not in the training: data, so a new or anonymous user who has an anonymous id. All user history captured in near realtime can be used to influence recommendations, there is no need to retrain to enable this.

So, if this time I get it correct, when a anon user lands on our website/app, we need to create a new unique id, let's say user: "anon-12345", then send an "event": "location-pref" for this "anon-12345" user, then send an "event": "app-pref" for the same user:anon-12345 and then query the recs engine like {"user":"anon-12345"}.

Is this the correct way?

[Pat Ferrel]

Yes correct.

However since there are relatively few location-prefs for countries and few app-prefs for apps the recommender  will have little to use in making recs. Do not expect them to be very good. Event types are best if the possible item ids are in the 1000’s like “buy".

Usually for an ecom site, Google has indexed pages and by far the most likely page type to be hit by an anon user is a product page. This allows several more events to be sent (product-detail-view for instance). But even better you can show item-based recs on an item page, which are far better than user based recs for anon users with no or very small history.

To view this discussion on the web visit https://groups.google.com/d/msgid/actionml-user/d285089d-fb4c-4eca-8772-dd34cb6e3d95n%40googlegroups.com.