1. Technical Field
This invention relates to website monitoring and the setting of cookies on client devices.
The invention as it relates to the setting of cookies on client devices is of use in website monitoring, but can also have other uses.
2. Related Art
Website monitoring or web analytics in itself is now fairly commonplace. Website monitoring/website analytics is used to monitor the performance and use of an organisation's website to help understand problems and ultimately improve the effectiveness of the site by improving “metrics” such as conversion rates and user experience, or preventing or detecting undesirable behaviour such as fraud.
What is now generally considered to be the method of choice for such monitoring is a technique which may be described as involving “client side page tagging”. These techniques in themselves are well understood and one such technique has been used for some time by the Applicants. An early version of this technique is explained in detail in the Applicants' earlier applications WO01/69412 and WO01/69386. In such techniques, it is now typical to put some script (for example JavaScript or Visual Basic Script) within a selection or each and every page of a website. As each page is visited, this script causes there to be communication with a server responsible for the collection of events describing users' journeys/interactions with the website and managing any necessary interaction with the client.
This approach however means that scripts running in one page during a visitor's use of a monitored site will have no way of communicating with scripts running in previous or subsequent pages viewed during the visit. This necessitates a mechanism that can link the data from such a sequence of pages into one “session”. The maintenance of this “session continuity” has been commonly achieved via the use of cookies, where the cookie is used to store a session ID. Cookies are only accessible within the domain in which they are set.
Here and throughout the specification, the expression “domain” is used in the sense used in relation to the Internet and “domain names”. Thus, a domain is defined by an Internet address xxx.com or xxx.co.uk and so on—i.e. by a top level domain name.
Cookies can be set or read by scripts running in the client browser, or by a web server communicating with the client.
Two types of cookies exist, these being first and third party cookies.
First party cookies are cookies that have been set within the domain of the page being viewed. This can be achieved by using either scripts executing within the page or by the web server(s) that are in the domain of the current page through the use of HTTP “set cookie” headers. f
Third party cookies are those that are set through the use of the HTTP “set cookie” headers by web server(s) that are not in the domain of the current page (these are third party web servers).
Script executing in the current page cannot read or set third party cookies. Any web server communicating with a client will only be sent cookies currently known to the browser that are within the web server's domain. This behaviour is part of the browser security model.
Hence third or first party cookies can be used to maintain session continuity. However, only third party cookies are able to maintain session continuity between domains. Due to security concerns, third party cookies are typically blocked by modern clients. This means that cross domain session tracking using third party cookies is ineffective.
Without third party cookies therefore, accurate cross domain session tracking has been impossible. Whilst there are circumstances where the use of third party cookies may be illegitimate or undesirable there can be circumstances where maintaining session continuity across domains is legitimate and desirable.
There are situations where this may be useful to the user and/or to an organisation which maintains websites in several different domains.
It is fairly typical for large organisations to maintain a number of websites which reside in different domains. There may, for example, be a different website for different areas of the business or a different website for each country (e.g. a .com site, a .co.uk site and so on). Thus, there may be a single enterprise with websites in different domains and the current technologies as outlined above are incapable in practical terms of allowing website monitoring across these different websites as they are visited by a user. Thus, for example, session continuity might be lost just as the user is moving to a point where he is about to make a purchase or a booking if that part of the operation is handled by a website running within a different domain.
Thus, an enterprise can be left in a situation where it has monitoring information in respect of each of its websites and could well know that many of these individual “partial sessions” in respect of the separate websites will actually relate to a single user and a single browser instance navigating across their various websites, but yet be unable to follow the whole interaction.
Brute force methods for trying to re-connect such partial sessions to give the overall picture are in reality complex, costly and unreliable. Such techniques generally only provide a best guess as to which partial sessions snap together.
Other methods exist to maintain session context across domains. Many of these are geared towards providing a single log-in across multiple domains. These typically use a series of requests and redirects to achieve the desired results. Such techniques are complex to implement and maintain.
Other possible solutions may use a customer database to maintain context. However, this approach causes problems because the customer ID will not necessarily be known at the start of a session and therefore initial phases of a visit cannot be related to later phases on other domains.