Location based personalisation and APIs

Location based personalisation is when a page is personalised for a user depending on their location. For example, a user from China could be shown a notification to visit a company’s Chinese micro-site, or users from India visiting a university website could be shown a block of content informing them about popular courses Indian students apply for. When used in this way, the marketing power of your website can be greatly enhanced.

An example using  jQuery

Below is an example using jQuery to make the request, and IPInfo location service to provide the user’s location based on their IP address:

$.get("https://ipinfo.io", function(response) {
  console.log(response.ip, response.country);
}, "jsonp");

A simple AJAX call is enough here to get the location data and do whatever we want with it. However, if we want replace other parts of the page for different countries we have to add them to this callback. We may be catering for dozens of other countries. This could work if we’re writing to a single script, but what if our web app has multiple JavaScript files? This separation means multiple API calls being made which is not very efficient. Worse yet, we may exceed our location service’s request limit and the service will no longer provide the data we need.

I faced this problem whilst I was applying personalisation to a previous company’s website. We had code in multiple JavaScript files that we used a task manager to combine, but this separation meant it was more desirable for us to be able to place different personalisation callback functions in different places. For example, we had some personalisation that applied to the entire app and would go in our app.js file, but code that applied only to the homepage would go in its own homepage.js.

Introducing ServiceQ

ServiceQ is a service queuing library I built to overcome this problem. It allows multiple requests to be initiated, but only one HTTP request will actually be made. The callbacks are queued until the response, which is stored internally in the library, then each is provided with the data to perform whatever personalisation is required.

Below is a simple example:

var serviceQ = new UoS_ServiceQ({
  request: {
    url: "https://ipinfo.io",
    dataType: "jsonp",
  }
});

serviceQ.do( function(data) {
  console.log("Service 1", data);
} );

serviceQ.do( function(data) {
  console.log("Service 2", data);
} );

In this example, only a single HTTP request is made. Also, the second do() function doesn’t fail because the response hasn’t arrived yet – the callbacks are simply put in an internal queue.

Storing the response for better performance

The below example uses getData and setData to store data in a cookie so that the data is kept for the entire browser session (or longer). This will improve performance as it doesn’t require additional HTTP requests to the location service. It will also require a smaller request limit from the provider which could also save money.

var serviceQ = new UoS_ServiceQ({
  request: {
    url: "https://ipinfo.io",
    dataType: "jsonp",
  },
  getData: function(data) {
    return Cookies.getJSON('UoS_LocationService__data');
  },
  setData: function(data) {
    Cookies.set('UoS_LocationService__data', data);
  }
});