{"_id":"588a70fbb39ea10f0047a7a4","parentDoc":null,"project":"5668fab608f90021008e882f","user":"5668fa9755e4b32100935d41","category":{"_id":"57fa65275ba65a17008b988f","__v":0,"version":"5668fab608f90021008e8832","project":"5668fab608f90021008e882f","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-10-09T15:41:27.321Z","from_sync":false,"order":7,"slug":"model-query-javascript","title":"Model query (Javascript)"},"version":{"_id":"5668fab608f90021008e8832","__v":19,"project":"5668fab608f90021008e882f","createdAt":"2015-12-10T04:08:22.769Z","releaseDate":"2015-12-10T04:08:22.769Z","categories":["5668fab708f90021008e8833","569740f124490c3700170a64","569742b58560a60d00e2c25d","569742bd0b09a41900b2446c","569742cd69393517000c82b3","569742f459a6692d003fad8f","569743020b09a41900b2446d","5697430b69393517000c82b5","56a17776470ae00d00c30642","56a2c48a831e2a0d0069b1ad","56b535757bccae0d00e9a1cd","56e1ff6aa49fdc0e005746b5","57e1c88115bf6522002a5e4e","57fa65275ba65a17008b988f","57fbeea34002550e004c032e","58474584889b6c2d00fb86e9","58475dcc64157f0f002f1907","587e7b5158666c2700965d4e","58a349fc30852819007ba083"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.18.0","version":"1.18"},"__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2017-01-26T21:58:19.749Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":8,"body":"This is an advanced and experimental feature and is not currently activated for all properties. If you would like to activate this feature for you, please get in touch with [Support](doc:support).\n\nIf you simply want to not show items older than a certain age, see our instructions to [Set max age for recommended items](doc:set-max-age-for-recommended-items).\n\nIn order for us to be able to apply time decay, you need to share the time of publication in the inventory items, with the field name `published_time` (in ISO 8601 format). For more information on that, see [Defining your Inventory](doc:defining-your-inventory).\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Why this is usually not needed\"\n}\n[/block]\nGenerally, if your goal is to optimize CTR or corresponding engagement metrics, explicit time decay rules are unnecessary and could be counterproductive. There are a couple of reasons:\n\n* Our machine learning system automatically infers attributes such as whether an item is trending or stale, relying on user behavior. This inference is usually smarter than blind reliance on time since publication. For instance, an article published a long time ago that has become topically relevant recently can get picked up as trending.\n* We should also smartly filter out items that users have already browsed or visited, and therefore people should not see an item again if they've already visited it.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Specify time decay globally, in inventory, and in queries (note: needs activation)\"\n}\n[/block]\nThe time-decayed score computed by LiftIgniter is added to the rest of the score we compute in order to determine the total score of each item.\n\nThere are two parameters that control the way time decay works. These can be specified in the `opts` in your register function.\n\n* `timeDecayInitialScore`: This is the initial score attached to an item that has just been published. Essentially, it determines how much importance the time-decayed score has in determining the ranking relative to the rest of the score.\n* `halfLifeInSeconds`: This is the time (in seconds) that it takes for the score to be halved.\n\nFor instance, if you set a value of `timeDecayInitialScore` of 16 and a `halfLifeInSeconds` of 86400 (so 1 day), then the score for a just published item would be 16, the score for an item that is 1 day old would be 8, the score for an item that is 2 days old would be 4, the score for an item that is 3 days old would be 2, and so on.\n\nThe decay operates continuously (as [exponential decay](https://en.wikipedia.org/wiki/Exponential_decay)). So an item that is half a day old would have a score somewhere between the score for a brand-new item and an item that is 1 day old.\n\nAs alternatives to specifying the parameters `timeDecayInitialScore` and `halfLifeInSeconds` as part of the query, you can:\n\n* Give us the values so we can set those up as the default values (default values are overridden by the values specified in the query, if you choose to so specify them).\n* Specify them as part of individual inventory items (so that you can vary them based on the item). This would allow you to decay different items at different rates. The value within an individual inventory item, if present, takes precedence over default values and over the values specified in the query.","excerpt":"","slug":"set-time-decay","type":"basic","title":"Set time decay"}
This is an advanced and experimental feature and is not currently activated for all properties. If you would like to activate this feature for you, please get in touch with [Support](doc:support). If you simply want to not show items older than a certain age, see our instructions to [Set max age for recommended items](doc:set-max-age-for-recommended-items). In order for us to be able to apply time decay, you need to share the time of publication in the inventory items, with the field name `published_time` (in ISO 8601 format). For more information on that, see [Defining your Inventory](doc:defining-your-inventory). [block:api-header] { "type": "basic", "title": "Why this is usually not needed" } [/block] Generally, if your goal is to optimize CTR or corresponding engagement metrics, explicit time decay rules are unnecessary and could be counterproductive. There are a couple of reasons: * Our machine learning system automatically infers attributes such as whether an item is trending or stale, relying on user behavior. This inference is usually smarter than blind reliance on time since publication. For instance, an article published a long time ago that has become topically relevant recently can get picked up as trending. * We should also smartly filter out items that users have already browsed or visited, and therefore people should not see an item again if they've already visited it. [block:api-header] { "type": "basic", "title": "Specify time decay globally, in inventory, and in queries (note: needs activation)" } [/block] The time-decayed score computed by LiftIgniter is added to the rest of the score we compute in order to determine the total score of each item. There are two parameters that control the way time decay works. These can be specified in the `opts` in your register function. * `timeDecayInitialScore`: This is the initial score attached to an item that has just been published. Essentially, it determines how much importance the time-decayed score has in determining the ranking relative to the rest of the score. * `halfLifeInSeconds`: This is the time (in seconds) that it takes for the score to be halved. For instance, if you set a value of `timeDecayInitialScore` of 16 and a `halfLifeInSeconds` of 86400 (so 1 day), then the score for a just published item would be 16, the score for an item that is 1 day old would be 8, the score for an item that is 2 days old would be 4, the score for an item that is 3 days old would be 2, and so on. The decay operates continuously (as [exponential decay](https://en.wikipedia.org/wiki/Exponential_decay)). So an item that is half a day old would have a score somewhere between the score for a brand-new item and an item that is 1 day old. As alternatives to specifying the parameters `timeDecayInitialScore` and `halfLifeInSeconds` as part of the query, you can: * Give us the values so we can set those up as the default values (default values are overridden by the values specified in the query, if you choose to so specify them). * Specify them as part of individual inventory items (so that you can vary them based on the item). This would allow you to decay different items at different rates. The value within an individual inventory item, if present, takes precedence over default values and over the values specified in the query.