{"_id":"5845fadc8584d02500ec8edb","category":{"_id":"5697430b69393517000c82b5","version":"5668fab608f90021008e8832","__v":3,"pages":["56975a3d59a6692d003fadae","56a2c3dff4f3410d008a84dc","56d88ca37a04df0b00ddf1c7"],"project":"5668fab608f90021008e882f","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-14T06:41:15.588Z","from_sync":false,"order":10,"slug":"faq-troubleshooting","title":"FAQ / Troubleshooting"},"__v":0,"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"},"parentDoc":null,"project":"5668fab608f90021008e882f","user":"5668fa9755e4b32100935d41","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-12-05T23:40:12.576Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":7,"body":"A number of our customers like to test their widget design and interface in a development environment prior to launching it in production.\n\nThere are a few different ways of doing this, each with its pros and cons.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Maintain different production and development organizations\"\n}\n[/block]\nWe can give you a separate set of keys and associated JavaScript snippet that you can use for your development website. With separate keys, *everything* is kept separate between the two organizations. In particular, the organizations have:\n\n* Separate inventory\n* Separate activity\n* Separate machine-learned models based on the inventory and activity\n\nIf you choose to go down this route, it's important to remember:\n\n* The actual inventory items recommended will be from the development organization. In particular, they will be limited to items for which we have seen some activity on the development organization, which could be a small subset of items.\n* The recommendations will be based purely on development organization, and therefore will be heavily swayed by the non-representative action of the small number of people accessing that organization.\n\nWith these caveats, this separate setup might still be good enough for you to test the recommendation display and integration details.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Only one production key, development environment fetches production recommendations\"\n}\n[/block]\nYou can just have one organization for your production environment. In the development environment, you use the same key, thereby fetching production recommendations.\n\nThe main caveat here is that you should make sure that the development environment does not pollute the production activity or inventory streams. You also need to keep in mind that the recommendations we return may be suboptimal. We discuss these separately:\n\n* Inventory stream pollution: If the development environment has identical inventory to the production environment, this does not matter. If they have different inventory, you could block inventory sending from the development environment by specifying inventory.collect as false in your [$p(\"init\")][doc:pinit) call in the JavaScript snippet.\n* Activity stream pollution: This is generally a non-issue since the volume of activity on the development site is small relative to the production site.\n* Suboptimal recommendations (if URL structures do not match): If the URLs in the development environment do not match those in the production environment, we may not be able to correctly identify the user's context and therefore may return worse recommendations than we would in production.","excerpt":"","slug":"production-and-development-environments","type":"basic","title":"Production and development environments"}

Production and development environments


A number of our customers like to test their widget design and interface in a development environment prior to launching it in production. There are a few different ways of doing this, each with its pros and cons. [block:api-header] { "type": "basic", "title": "Maintain different production and development organizations" } [/block] We can give you a separate set of keys and associated JavaScript snippet that you can use for your development website. With separate keys, *everything* is kept separate between the two organizations. In particular, the organizations have: * Separate inventory * Separate activity * Separate machine-learned models based on the inventory and activity If you choose to go down this route, it's important to remember: * The actual inventory items recommended will be from the development organization. In particular, they will be limited to items for which we have seen some activity on the development organization, which could be a small subset of items. * The recommendations will be based purely on development organization, and therefore will be heavily swayed by the non-representative action of the small number of people accessing that organization. With these caveats, this separate setup might still be good enough for you to test the recommendation display and integration details. [block:api-header] { "type": "basic", "title": "Only one production key, development environment fetches production recommendations" } [/block] You can just have one organization for your production environment. In the development environment, you use the same key, thereby fetching production recommendations. The main caveat here is that you should make sure that the development environment does not pollute the production activity or inventory streams. You also need to keep in mind that the recommendations we return may be suboptimal. We discuss these separately: * Inventory stream pollution: If the development environment has identical inventory to the production environment, this does not matter. If they have different inventory, you could block inventory sending from the development environment by specifying inventory.collect as false in your [$p("init")][doc:pinit) call in the JavaScript snippet. * Activity stream pollution: This is generally a non-issue since the volume of activity on the development site is small relative to the production site. * Suboptimal recommendations (if URL structures do not match): If the URLs in the development environment do not match those in the production environment, we may not be able to correctly identify the user's context and therefore may return worse recommendations than we would in production.