I am developing an app and I need to tackle a problem here.

The app is kind of an e-commerce app where each user will be shown a list of items daily. The problem is, I need to keep a track of all the items seen by a user so that those items are not shown again.

How can I do this?

Approach I Maintain the ids of all the items seen by a user in a cache and check the cache each time a GET API call comes from a user.

Approach II Maintain a reverse mapping from item to user to avoid showing duplicate items.

  • option 4 show the same items to all users each day – Ewan Sep 16 '18 at 18:52
  • What is the business reason for not showing items to a user on subsequent days? How volatile is this data? My first thought was to store item keys in browser storage and avoid this kind of user-specific filtering on the server. – Dan Wilson Oct 17 '18 at 14:41
  • @DanWilson Consider this as a dating app like Tinder. If one profile has been shown to a user then I don't wanna show that one again. – coderahul94 Oct 18 '18 at 18:14

Just record the facts

I suggest maintaining a table containing facts rather than business concepts. Instead of tracking which products should not be shown (a business rule), simply keep track of when they are shown (an indisputable fact). In its most simple form such a table might have these fields:

UserID - FK to your user table
ItemID - FK to the item shown
TimeShown - UTC timestamp the moment the item was shown

From there, you can implement the business logic in application code (which is much easier to version than database schema) by leveraging these facts, e.g.

  • Show no item that has ever been shown (as in your question)
  • No repeats for 30 days
  • Item is only visible for 24 hours, then it is hidden
  • The site contains a "See my previous offers" link which allows a user to browse products that they may remember seeing but can no longer find

You can implement all of these functional behaviors without ever having to alter the table.

| improve this answer | |

Here some more ideas (I prefer 1, it's close to your second approach):

  1. a plain indexed database table for user ID item ID pairs (as combined key) might suffice. An additional column that counts the views by the user might help for targeted advertising.

  2. combine user ID and item ID and use them as a key for a bloom filter. In this case the user might never see certain items because of false positives, but depending on your use case that might be ok. If this is not ok, you can double check positives with a database table (see 1, with a "where in" clause).

  3. store the last x items a client has seen and respect them when showing items to the client. This list might be even stored on the client side and send as cookie.

  4. some hash function magic to select item IDs to show to the user. This way you don't have to store anything and the risk of duplicates is relatively low.

  5. create a daily item selection for all users or user clusters. This way you can reduce the amount of data you have to store tremendously. This ignores the fact that users don't visit daily or what they view in the shop.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.