Documentation
Cookies in biNu
biNu supports the use of cookies to store and retrieve information for a particular user on an application. The biNu Proxy Server uses the handset deviceId to access the correct cookie for each unique user.
A biNu application developer can therefore make use of this feature to personalise the experience for its users.
See sample code for examples of cookies in use within existing biNu applications.
Standard biNu Proxy Server cookies
The biNu Proxy Server always sets 4 cookies on every request that it sends to an application. These are:
- binusys_device_id – the deviceId of the handset making the request, e.g. '2546'
- binusys_ip_addr – the IP address of the handset making the request, e.g. '125.23.34.123'
- binusys_user_agent – the user agent of the handset making the request e.g. 'nokia 6700'
- binusys_size – the screen size of the handset making the request e.g. '240×320'
In addition to these special cases, the app developer is free to set values for any number of other cookies that can be used for the application user experience.
E.g. in PHP you could set a cookie as follows
setcookie('screen_width', 180, time()+86400*365);
The cookies follow normal HTTP cookie behaviour. The app developer can specify a duration for the cookie, create session only cookies, restrict the scope of the cookies to a given path, etc.
Cookies and caching
Setting cookies has an impact on how page impressions are cached. Normally the biNu Proxy Server will serve a cached impression if another device requests exactly the same content. However if a new cookie is set on the response or the same cookie is set with a different value, the biNu Proxy Server will create a new impression. The binusys cookies specified above are ignored with respect to caching.
Shared Content
biNu optimises the delivery of content to a network of users. As part of the optimisation it operates as a typical web proxy server in that it will request the content once from the application and they re-use the same response to service many clients.
biNu optimises the round trip time between the client and the proxy so a major part in any delays experienced by the user is the network lag and response time communicating with the application.
As well as the application delay, there is also a small delay in the proxy as it renders a page and determines a set of impressions. If the page is being shared between phones with identical properties, biNu can detect this and realise that it can share the same impression set. This can shave further milliseconds off any delay experinced by the user.
Where an application has significant Spidering of pages there will be an increased numbers of page requests and load on application servers. Sharing content between users can significantly reduce the load associatred with spidering.
Requirements for sharing
For content to be shared between users, the URLs must be identical and all valid user cookies must be the same (differences in biNu system cookies are ignored) If the developer wants to ensure content is never shared between users it is only necessary to ensure that
- all URLs are unique or
- at least one cookie is unique to each user.
Different screen sizes
Sometimes a developer may wish to prevent caching on all pages even if the content is identical. An example of this is where the application designer wishes to serve slightly different layouts of content depending on the specific screen size of each user. In these cases, the app developer must set a cookie e.g. screen_width = 180 to ensure that the proxy does not serve a cached version of the page which is the wrong size for the user's device.
Avoid disabling sharing
A developer may accidentally disable the sharing of content by defining a cookie which is unique to a user but has no implication for determining the content being displayed. The proxy will see that 2 cookies have different values and will not allow the sharing of the content. If all content can be shared, the user developer should avoid creating cookies that are unique to the user. If some content on a site can be shared and some can't the developer should differentiate the content using different paths in the URLs and resticting the cookies to requests with the appropriate paths.