You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: lib/recombee_api_client/api/item_based_recommendation.rb
+9-3Lines changed: 9 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,12 @@ class ItemBasedRecommendation < ApiRequest
21
21
#
22
22
# * *Optional arguments (given as hash optional)*
23
23
# - +targetUserId+ -> ID of the user who will see the recommendations.
24
+
#
25
+
#Specifying the *targetUserId* is beneficial because:
26
+
#
27
+
#* It makes the recommendations personalized
28
+
#* Allows calculations of Actions and Conversions in the graphical user interface, as Recombee can pair the user who got recommendations and who afterwards viewed/purchased an item.
29
+
#
24
30
# - +userImpact+ -> If *targetUserId* parameter is present, the recommendations are biased towards the user given. Using *userImpact*, you may control this bias. For an extreme case of `userImpact=0.0`, the interactions made by the user are not taken into account at all (with the exception of history-based blacklisting), for `userImpact=1.0`, you'll get user-based recommendation. The default value is `0.1`
25
31
#
26
32
# - +filter+ -> Boolean-returning [ReQL](https://docs.recombee.com/reql.html) expression which allows you to filter recommended items based on the values of their attributes.
@@ -70,11 +76,11 @@ class ItemBasedRecommendation < ApiRequest
70
76
#
71
77
# - +diversity+ -> **Expert option** Real number from [0.0, 1.0] which determines how much mutually dissimilar should the recommended items be. The default value is 0.0, i.e., no diversification. Value 1.0 means maximal diversification.
72
78
#
73
-
# - +minRelevance+ -> **Expert option** Specifies the threshold of how much relevant must the recommended items be to the user. Possible values one of: "low", "medium", "high". The default value is "low", meaning that the system attempts to recommend number of items equal to *count* at any cost. If there are not enough data (such as interactions or item properties), this may even lead to bestseller-based recommendations to be appended to reach the full *count*. This behavior may be suppressed by using "medium" or "high" values. In such case, the system only recommends items of at least the requested qualit, and may return less than *count* items when there is not enough data to fulfill it.
79
+
# - +minRelevance+ -> **Expert option** If the *targetUserId* is provided: Specifies the threshold of how much relevant must the recommended items be to the user. Possible values one of: "low", "medium", "high". The default value is "low", meaning that the system attempts to recommend number of items equal to *count* at any cost. If there are not enough data (such as interactions or item properties), this may even lead to bestseller-based recommendations to be appended to reach the full *count*. This behavior may be suppressed by using "medium" or "high" values. In such case, the system only recommends items of at least the requested qualit, and may return less than *count* items when there is not enough data to fulfill it.
74
80
#
75
-
# - +rotationRate+ -> **Expert option** If your users browse the system in real-time, it may easily happen that you wish to offer them recommendations multiple times. Here comes the question: how much should the recommendations change? Should they remain the same, or should they rotate? Recombee API allows you to control this per-request in backward fashion. You may penalize an item for being recommended in the near past. For the specific user, `rotationRate=1` means maximal rotation, `rotationRate=0` means absolutely no rotation. You may also use, for example `rotationRate=0.2` for only slight rotation of recommended items.
81
+
# - +rotationRate+ -> **Expert option** If the *targetUserId* is provided: If your users browse the system in real-time, it may easily happen that you wish to offer them recommendations multiple times. Here comes the question: how much should the recommendations change? Should they remain the same, or should they rotate? Recombee API allows you to control this per-request in backward fashion. You may penalize an item for being recommended in the near past. For the specific user, `rotationRate=1` means maximal rotation, `rotationRate=0` means absolutely no rotation. You may also use, for example `rotationRate=0.2` for only slight rotation of recommended items.
76
82
#
77
-
# - +rotationTime+ -> **Expert option** Taking *rotationRate* into account, specifies how long time it takes to an item to fully recover from the penalization. By example, `rotationTime=7200.0` means that items recommended more than 2 hours ago are definitely not penalized anymore. Currently, the penalization is linear, so for `rotationTime=7200.0`, an item is still penalized by `0.5` to the user after 1 hour.
83
+
# - +rotationTime+ -> **Expert option** If the *targetUserId* is provided: Taking *rotationRate* into account, specifies how long time it takes to an item to fully recover from the penalization. For example, `rotationTime=7200.0` means that items recommended more than 2 hours ago are definitely not penalized anymore. Currently, the penalization is linear, so for `rotationTime=7200.0`, an item is still penalized by `0.5` to the user after 1 hour.
Copy file name to clipboardExpand all lines: lib/recombee_api_client/api/set_item_values.rb
+9-28Lines changed: 9 additions & 28 deletions
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,12 @@
1
-
#
2
-
# This file is auto-generated, do not edit
3
-
#
4
-
5
1
moduleRecombeeApiClient
6
-
require_relative'request'
2
+
require_relative'set_values'
7
3
require_relative'../errors'
8
4
9
5
##
10
6
#Set/update (some) property values of a given item. The properties (columns) must be previously created by [Add item property](https://docs.recombee.com/api.html#add-item-property).
11
7
#
12
-
classSetItemValues < ApiRequest
13
-
attr_reader:item_id,:values
8
+
classSetItemValues < SetValues
9
+
attr_reader:item_id
14
10
attr_accessor:timeout
15
11
attr_accessor:ensure_https
16
12
@@ -26,39 +22,24 @@ class SetItemValues < ApiRequest
26
22
# "product_description": "4K TV with 3D feature",
27
23
# "categories": ["Electronics", "Televisions"],
28
24
# "price_usd": 342,
25
+
# "in_stock_from": "2016-11-16T08:00Z",
29
26
# "!cascadeCreate": true
30
27
# }
31
28
#```
32
29
#
33
30
#Special parameter `!cascadeCreate` may be used. It indicates that the item of the given itemId should be created if it does not exist in the database, as if the corresponding PUT method was used. Note the exclamation mark (!) at the beginning of the parameter's name to distinguish it from item property names.
34
31
#
35
32
#
36
-
definitialize(item_id,values)
33
+
# * *Optional arguments (given as hash optional)*
34
+
# - +cascadeCreate+ -> Sets whether the item should be created if not present in the database.
Copy file name to clipboardExpand all lines: lib/recombee_api_client/api/set_user_values.rb
+8-32Lines changed: 8 additions & 32 deletions
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,12 @@
1
-
#
2
-
# This file is auto-generated, do not edit
3
-
#
4
-
5
1
moduleRecombeeApiClient
6
-
require_relative'request'
2
+
require_relative'set_values'
7
3
require_relative'../errors'
8
4
9
5
##
10
6
#Set/update (some) property values of a given user. The properties (columns) must be previously created by [Add user property](https://docs.recombee.com/api.html#add-user-property).
11
7
#
12
-
classSetUserValues < ApiRequest
13
-
attr_reader:user_id,:values
8
+
classSetUserValues < SetValues
9
+
attr_reader:user_id
14
10
attr_accessor:timeout
15
11
attr_accessor:ensure_https
16
12
@@ -25,39 +21,19 @@ class SetUserValues < ApiRequest
25
21
# {
26
22
# "country": "US",
27
23
# "sex": "F",
28
-
# "!cascadeCreate": true
29
24
# }
30
25
#```
31
26
#
32
-
#Special parameter `!cascadeCreate` may be used. It indicates that the user of the given userId should be created if it does not exist in the database, as if the corresponding PUT method was used. Note the exclamation mark (!) at the beginning of the parameter's name to distinguish it from user property names.
33
-
#
27
+
# * *Optional arguments (given as hash optional)*
28
+
# - +cascadeCreate+ -> Sets whether the item should be created if not present in the database.
Copy file name to clipboardExpand all lines: lib/recombee_api_client/api/user_based_recommendation.rb
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -71,7 +71,7 @@ class UserBasedRecommendation < ApiRequest
71
71
#
72
72
# - +rotationRate+ -> **Expert option** If your users browse the system in real-time, it may easily happen that you wish to offer them recommendations multiple times. Here comes the question: how much should the recommendations change? Should they remain the same, or should they rotate? Recombee API allows you to control this per-request in backward fashion. You may penalize an item for being recommended in the near past. For the specific user, `rotationRate=1` means maximal rotation, `rotationRate=0` means absolutely no rotation. You may also use, for example `rotationRate=0.2` for only slight rotation of recommended items.
73
73
#
74
-
# - +rotationTime+ -> **Expert option** Taking *rotationRate* into account, specifies how long time it takes to an item to fully recover from the penalization. By example, `rotationTime=7200.0` means that items recommended more than 2 hours ago are definitely not penalized anymore. Currently, the penalization is linear, so for `rotationTime=7200.0`, an item is still penalized by `0.5` to the user after 1 hour.
74
+
# - +rotationTime+ -> **Expert option** Taking *rotationRate* into account, specifies how long time it takes to an item to fully recover from the penalization. For example, `rotationTime=7200.0` means that items recommended more than 2 hours ago are definitely not penalized anymore. Currently, the penalization is linear, so for `rotationTime=7200.0`, an item is still penalized by `0.5` to the user after 1 hour.
0 commit comments