{"_id":"56e218eabf97591700e72321","parentDoc":null,"githubsync":"","__v":11,"category":{"_id":"56e1ff6aa49fdc0e005746b5","__v":2,"pages":["56e218eabf97591700e72321","56e218fd30de321700b7e8d2"],"project":"5668fab608f90021008e882f","version":"5668fab608f90021008e8832","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-03-10T23:12:42.527Z","from_sync":false,"order":8,"slug":"js-sdk-api-integration","title":"JS SDK + API Integration"},"user":"5668fa9755e4b32100935d41","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"},"project":"5668fab608f90021008e882f","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-03-11T01:01:30.345Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"One way of implementing LiftIgniter is using JavaScript SDK on the frontend to take care of sending user activities to us, and making model query requests from your backend to build the recommendation into the page (or even send us the inventory item instead of the JS scraping).\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"LiftIgniter Cookies\"\n}\n[/block]\nThese are the cookies our JS SDK uses. You can extract them by referring to their cookie name, and attach it to the model query with the corresponding parameter names.\n\n*** Make sure your codes are robust enough to handle the cases where the cookie doesn't exist. Because the cookie won't exist on user's first request to server. ***\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Cookie Name\",\n    \"h-1\": \"Query Parameter Name\",\n    \"h-2\": \"Description\",\n    \"0-0\": \"_ig\",\n    \"0-1\": \"userId\",\n    \"0-2\": \"This is the randomly generated UUID we use to identify a unique user. It's also used by our A/B test slicing, and you can change this value from the client side with the function $p(\\\"setUserId\\\", \\\"example_id\\\"). \\n\\nThis field will be empty if you have to make a recommendation to a user who has never entered this site before.\",\n    \"1-0\": \"_igt\",\n    \"1-1\": \"sessionId\",\n    \"1-2\": \"Randomly generated string to identify a unique session a user is in.\",\n    \"2-0\": \"_igg\",\n    \"2-1\": \"gid\",\n    \"2-2\": \"This is a cross-site global user ID. It may not always be available. We recommend including it if available. It is necessary for some aspects of cross-site recommendations to work.\"\n  },\n  \"cols\": 3,\n  \"rows\": 3\n}\n[/block]\n\n[block:api-header]\n{\n  \"title\": \"PageviewId and deduplication\"\n}\n[/block]\nAs a best practice, you should include the `pageviewId` of the current page. This will give us accurate information tying the request to the pageview, and will also enable deduplication of recommendations between earlier and later requests. The function you can run in JavaScript to extract LiftIgniter's pageviewId is:\n\n$p(\"getPageviewId\");\n\nSending both `userId` and `pageviewId` allow us to deduplicate recommendations between queries that have the same pageviewId and userId (e.g., different areas on the same page). \n\nNote however that we only deduplicate if the requests are made serially; we deduplicate between a request and previous completed requests, but we do not deduplicate between requests made in parallel. If you need to make multiple requests on the same `userId ` and `pageviewId` in parallel and want deduplication, you should request more items than you need for each widget and handle the deduplication yourself. \n\nIf you are unable to send `pageviewId` (for instance, because you request recommendations before the LiftIgniter snippet executes), our recommendations will still work, but you will not be able to avail of within-page deduplication of recommendations, and some advanced analytics and diagnostics may be unavailable to you (however, all our main Analytics should continue to work normally).\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Other Parameters\"\n}\n[/block]\nFollowing are the parameters that our JavaScript SDK collects, but aren't stored in the cookie. If you are making a query from backend you'll have to keep track most of these things yourself. However, this parameters are optional and aren't as important as the ones discussed above except for `url` field.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Query Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"url\",\n    \"1-0\": \"referrer\",\n    \"2-0\": \"host\",\n    \"3-0\": \"userAgent\",\n    \"4-0\": \"os\",\n    \"0-1\": \"Current url that the user is on. This is an important field for knowing user's current context. If you have agreed to use some other field as content ID, then change the parameter name to whatever we agreed on.\",\n    \"1-1\": \"Referrer to the site. Potentially useful for you if you want to set a rule to certain recommendations (i.e. only show these types of recommendation for people coming in from facebook).\",\n    \"2-1\": \"Host of client, so that we can infer appropriate recommendation from user's physical location.\",\n    \"3-1\": \"User agent of the user's computer.\",\n    \"4-1\": \"Operating system of the user.\",\n    \"5-0\": \"language\",\n    \"5-1\": \"User's language.\"\n  },\n  \"cols\": 2,\n  \"rows\": 6\n}\n[/block]\nAn example query's parameter will look like the following:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"apiKey\\\" : \\\"your api key here\\\",\\n  \\\"maxCount\\\" : 10,\\n  \\\"requestFields\\\" : [\\\"list\\\",\\\"of\\\",\\\"fields\\\"],\\n  \\\"requestFieldsAON\\\" : true,\\n  \\\"timestamp\\\" : 1400464843310,\\n  \\\"url\\\" : \\\"http://www.dummydomain.com/a-beautiful-sea.html\\\",\\n  \\\"userId\\\" : \\\"de305d54-75b4-431b-adb2-eb6b9e546013\\\",\\n  \\\"referrer\\\" : \\\"http://www.dummydomain.com/holiday-resorts.html\\\"\\n}\",\n      \"language\": \"json\"\n    }\n  ]\n}\n[/block]\nFor cross-site recommendations from backend, see the Cross-site recommendations from backend section at [Cross-site recommendation](doc:cross-site-recommendation).","excerpt":"","slug":"model-queries-from-backend","type":"basic","title":"Model Queries from Backend"}

Model Queries from Backend


One way of implementing LiftIgniter is using JavaScript SDK on the frontend to take care of sending user activities to us, and making model query requests from your backend to build the recommendation into the page (or even send us the inventory item instead of the JS scraping). [block:api-header] { "type": "basic", "title": "LiftIgniter Cookies" } [/block] These are the cookies our JS SDK uses. You can extract them by referring to their cookie name, and attach it to the model query with the corresponding parameter names. *** Make sure your codes are robust enough to handle the cases where the cookie doesn't exist. Because the cookie won't exist on user's first request to server. *** [block:parameters] { "data": { "h-0": "Cookie Name", "h-1": "Query Parameter Name", "h-2": "Description", "0-0": "_ig", "0-1": "userId", "0-2": "This is the randomly generated UUID we use to identify a unique user. It's also used by our A/B test slicing, and you can change this value from the client side with the function $p(\"setUserId\", \"example_id\"). \n\nThis field will be empty if you have to make a recommendation to a user who has never entered this site before.", "1-0": "_igt", "1-1": "sessionId", "1-2": "Randomly generated string to identify a unique session a user is in.", "2-0": "_igg", "2-1": "gid", "2-2": "This is a cross-site global user ID. It may not always be available. We recommend including it if available. It is necessary for some aspects of cross-site recommendations to work." }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "title": "PageviewId and deduplication" } [/block] As a best practice, you should include the `pageviewId` of the current page. This will give us accurate information tying the request to the pageview, and will also enable deduplication of recommendations between earlier and later requests. The function you can run in JavaScript to extract LiftIgniter's pageviewId is: $p("getPageviewId"); Sending both `userId` and `pageviewId` allow us to deduplicate recommendations between queries that have the same pageviewId and userId (e.g., different areas on the same page). Note however that we only deduplicate if the requests are made serially; we deduplicate between a request and previous completed requests, but we do not deduplicate between requests made in parallel. If you need to make multiple requests on the same `userId ` and `pageviewId` in parallel and want deduplication, you should request more items than you need for each widget and handle the deduplication yourself. If you are unable to send `pageviewId` (for instance, because you request recommendations before the LiftIgniter snippet executes), our recommendations will still work, but you will not be able to avail of within-page deduplication of recommendations, and some advanced analytics and diagnostics may be unavailable to you (however, all our main Analytics should continue to work normally). [block:api-header] { "type": "basic", "title": "Other Parameters" } [/block] Following are the parameters that our JavaScript SDK collects, but aren't stored in the cookie. If you are making a query from backend you'll have to keep track most of these things yourself. However, this parameters are optional and aren't as important as the ones discussed above except for `url` field. [block:parameters] { "data": { "h-0": "Query Parameter", "h-1": "Description", "0-0": "url", "1-0": "referrer", "2-0": "host", "3-0": "userAgent", "4-0": "os", "0-1": "Current url that the user is on. This is an important field for knowing user's current context. If you have agreed to use some other field as content ID, then change the parameter name to whatever we agreed on.", "1-1": "Referrer to the site. Potentially useful for you if you want to set a rule to certain recommendations (i.e. only show these types of recommendation for people coming in from facebook).", "2-1": "Host of client, so that we can infer appropriate recommendation from user's physical location.", "3-1": "User agent of the user's computer.", "4-1": "Operating system of the user.", "5-0": "language", "5-1": "User's language." }, "cols": 2, "rows": 6 } [/block] An example query's parameter will look like the following: [block:code] { "codes": [ { "code": "{\n \"apiKey\" : \"your api key here\",\n \"maxCount\" : 10,\n \"requestFields\" : [\"list\",\"of\",\"fields\"],\n \"requestFieldsAON\" : true,\n \"timestamp\" : 1400464843310,\n \"url\" : \"http://www.dummydomain.com/a-beautiful-sea.html\",\n \"userId\" : \"de305d54-75b4-431b-adb2-eb6b9e546013\",\n \"referrer\" : \"http://www.dummydomain.com/holiday-resorts.html\"\n}", "language": "json" } ] } [/block] For cross-site recommendations from backend, see the Cross-site recommendations from backend section at [Cross-site recommendation](doc:cross-site-recommendation).