-setdcy template: pers?clnt=<name|pass>&com=setdcy&<ftr_group_1>=<decay_rate_1>&... Order of query params is important: position of 'com' is not important, however updates of feature group decay rates are performed in the order they appear in the request. Decay rate must exist and be a number from 0 to 1, both inclusive (eg: 0.5). Feature group is a template path expression 'pathname', representing all features with name starting with 'pathname'. Feature group cannot be "*". descript: if the feature group already exists in the DB, the corresponding decay rate is updated to the new value. If the feature group is a new group, the new (group, rate) pair is inserted in the DB. If the error code 401 is returned, (eg. in case some decay rate was not numeric or was not in the proper range, or in case the feature group was illegal, eg. "*") then no changes at all have taken place in the DB. Note however that in case a feature group is the empty string, the corresponding (group, rate) pair will just be ignored. example : pers?clnt=name|pass&com=setdcy&page10.banners=0.5&the_times.politics=1 pers?clnt=name|pass&com=setdcy&frequency.allfeatures=0 (see comments) returns : 200 OK, 401 (fail, request error), 501 (fail, server error) 200 OK : no response body exists. comments: - Note that if rate is set to 0, the decay calculated for a feature is reduced to the total number of visits the user paid to the feature. - Note that the same feature may be organized as part of two different hierarchies, eg. page10.banners.banner2, frequency.allfeatures.banner2, with possibly different rates. In this case, when the feature is selected by a user, the application must notify the server about the interaction for both (or more) names of the feature. - Note that it is possible to define overlapping sets of features, or sets who are subsets of other sets, giving possibly different rates for each, as in: pers?clnt=name|pass&com=setdcy&page10=0.3&page10.banners=0.6 This will not result in more user-feature interactions recorded in the database (as is the case in the previous situation). The interactions are recorded strictly as the application dictates. However, this makes it posible for the application to query the same interaction data in different ways. By defining various overlapping and competing feature groups and assigning them different decay rates, the application may get different decay values for a (feature, user) pair. - Note that it is not necessary to register a feature group in 'decay_groups' in order to use the decay functionality. The decay service is based only on 'decay_data' table, and populating this table has nothing to do with defining feature groups. It is possible to define s group and a corresponding decay rate on the fly, in the request that calculates the decay values. The table 'decay_groups' is just a convenient place to store groups and rates in order not to repeat them in every 'caldcy' request.