WO2001069412A2

WO2001069412A2 - Monitoring and modifying services provided over a network

Info

Publication number: WO2001069412A2
Application number: PCT/GB2001/001113
Authority: WO
Inventors: Malcolm John Duckett; Jeremy Andrew Charles Barker; Rhys Andrew Newman
Original assignee: Speed-Trap.Com Ltd.
Priority date: 2000-03-14
Filing date: 2001-03-14
Publication date: 2001-09-20
Also published as: WO2001069386A3; AU2001240844A1; AU4082601A; EP1264261A2; WO2001069386A2; DE60114999D1; ATE310282T1; WO2001069412A3; DE60114999T2; US20030053420A1; EP1264261B1

Abstract

A method for customer relations management in respect of services provided over a network comprising the steps of monitoring a user's interaction with a service provided over a network; and modifying the service in response to the monitored interactions. The user's interactions are monitored by use of an applet (102) running within the user's browser and are forwarded to a central unit (41). From here the interactions may be passed to a personalisation engine (200), which can use the gathered information to alter the service being used by the user, in particular web pages may be changed in response to a user's actions.

Description

Monitoring and Modifying Services provided over a

Network

This invention relates to monitoring and modifying services provided over a network. In particular it relates to monitoring and modifying services provided over an intranet and/or the Internet and particularly the World Wide Web- There is currently great interest and activity in providing services via networks and particularly the World Wide Web. However, some difficulties arise for providers and users in providing and using such services. In particular, waiting for web pages to download from the World Wide Web can be time consuming and this factor together with a poorly designed website can severely limit the efficiency of web based services. Whilst these difficulties with web based services are widely appreciated, there have, to date, been no satisfactory systems available for gaining data concerning the effectiveness and usability of any given web based service. Existing systems tend to provide generalised information by monitoring networks and servers.

It has been appreciated that obtaining detailed information concerning the use made of websites by individual users can be invaluable in enhancing the services which are provided over the Internet and particularly the World Wide Web. Further, there is a desire to target services provided to individual users. This can make services much more effective and ultimately more profitable. The term customer relations management is sometimes used in connection with the business of targeting or personalizing services. It is an object of this invention to provide systems for monitoring the use, operation and/or performance of services provided over a network. At least some embodiments are directed to obtaining information concerning how the performance of the service is perceived by users . Other embodiments are directed to systems for personalizing provided services.

According to a first aspect of the present invention there is provided a method for customer relations management in respect of services provided over a network comprising the steps of: monitoring a user ' s interaction with a service provided over a network; and modifying the service in response to the monitored interactions.

Preferably the monitoring and modifying occur in real time. This can mean that modifications can be made whilst the user is still interacting with the service. The service may be such that a user interacts with the service via one or more electronic pages such as web pages. In such a case modifications can be made to an electronic page whilst the user is skill interacting with that page. It will be appreciated that the modifications made can be tailored to particular individuals and that whilst the method above refers to a single user, in practice a system implementing the method will typically independently perform the steps for a large number of users. Typically the method will be implemented using a communications network. Further, the service will typically be provided over the network to a plurality of end user communications units and the step of monitoring a user's interaction with the service will typically comprise the step of receiving at a central unit, information obtained at, and output by, a respective end user communications unit. According to a second aspect of the present invention there is provided a method for monitoring use of a service provided over a network to a plurality of end user communications units to facilitate customer relations management, the method comprising the step of: receiving at a central unit, information obtained at each end user communications unit during monitoring of activity associated with the service, and supplying data based on said information to a personalization engine to allow modification of the service in dependence on the monitored activity. According to a third aspect of the present invention there is provided a method of operating an end user communications unit for use in a network services customer relations management system, the communications unit being arranged to allow reception of services provided over the network and the method comprising the steps of monitoring activity, at the communications unit, associated with a service provided over the network and outputting information so obtained to allow modification of the service to be performed in dependence on the monitored activity.

Typically the service will be one which is accessed via one or more electronic page, such as a web page.

The information obtained during monitoring will typically comprise details of a user's interaction with an electronic page. The details may include a log of pointing device position and may further include a log of selecting operation.

Preferably the monitoring and outputting steps performed at the end user communications unit are facilitated by an applet which runs within a browser and runs in a language which is cross-platform.

In some cases, the information concerning users' interaction with the service will be sent directly to the central unit for analysis. In other cases, the information may be pre-analysed at the respective communications unit. The respective communications unit may be arranged to detect predetermined user activity. Further, the communications unit may be arranged to output a predetermined type of signal on detection of the predetermined activity. Where an applet facilitates operation of the end user communications unit, the applet may be arranged to control any one of or any combination of the analysis, detection and signalling mentioned above. In general, information gained in the monitoring step will be forwarded to a personalization engine which is arranged to determine appropriate changes to the service based on the forwarded information. The information may be pre-processed at the central unit and/or at the end user communications unit in order to provide targeted information to the personalization engine.

Preferably the step of modifying the service comprises the step of changing at least one of the electronic pages associated with the service, most preferably the electronic page being viewed by the user. This can allow, for example, a special offer banner or a special offer window to be displayed to a user whom it has been determined is interested in purchasing a particular item.

In a development rather than modifying the service provided over the network, the information gained may be used as the basis for a telephone call to the user offering assistance.

According to a fourth aspect of the present invention there is provided an end user communications unit for use in a network services customer relations management system, the communications unit being arranged to allow reception of services provided over the network, being arranged to monitor activity associated with a service provided over the network and being arranged to output information so obtained to allow modification of the service to be performed in dependence on the monitored activity.

According to a fifth aspect of the present invention there is provided a network services customer relations management system comprising: a plurality of end user communications units, each unit being arranged to allow reception of services provided over a network, being arranged to monitor activity associated with a service provided over the network and being arranged to output information so obtained, and a personalization engine which is arranged to receive information obtained at, and output by, the end user communications units, and to determine appropriate changes to the service provided to each user based on the received information.

Typically, the information will be forwarded to the personalization engine via a distinct central unit. However, in some cases the personalization engine may act as a central unit.

According to a sixth aspect of the present invention there is provided a computer program comprising code portions which when loaded and run on computer means cause the computer means to execute any method defined above.

According to a seventh aspect of the present invention there is provided a computer program comprising code portions which when loaded and run on computer means constitute any apparatus defined above. According to an eighth aspect of the present invention there is provided a method for monitoring operation of services provided over a network to a plurality of end user communications units, the method comprising the steps of: at each end user communications unit, monitoring activity associated with a service; and transmitting information obtained in the monitoring step to a central unit. The method may allow the performance of the service as perceived by users to be monitored.

According to a ninth aspect of the present invention there is provided apparatus for monitoring operation of services provided over a network, the apparatus comprising a central unit and a plurality of end user communications units which are arranged to allow reception of services provided over the network wherein each of the end user communications units is arranged to monitor activity associated with a service and to transmit information so obtained to the central unit. The method may allow the performance of the service as perceived by users to be monitored.

Such arrangements make use of the aggregate computing power available at the many user communications units which are typically connected to a network rather than attempting to support such data gathering with a single or a few central servers. It is also possible to collect data which is specific to the experience of each of a number of users .

According to a tenth aspect of the present invention there is provided an end user communications unit for use in a system for monitoring operation of services provided over a network, the communications unit being arranged to allow reception of services provided over the network, being arranged to monitor activity associated with a service provided over the network and being arranged to output information so obtained. The unit may allow the performance of the service as perceived by users to be monitored.

According to an eleventh aspect of the present invention there is provided a method of operating an end user communications unit for use in a system for monitoring operation of services provided over a network, the communications unit being arranged to allow reception of services provided over the network and the method comprising the steps of monitoring activity, at the communications unit, associated with a service provided over the network and outputting information so obtained. The method may allow the performance of the service as perceived by users to be monitored.

According to a twelfth aspect of the present invention there is provided a method of testing a server based system comprising the steps of: monitoring and recording activities instigated by at least one user when using the services supported by the server system; and playing back activities recorded in the above step.

According to a thirteenth aspect of the present invention there is provided apparatus for testing a server based system, the apparatus comprising at least one end user communications unit which is arranged to allow reception of services supported by the server wherein, the end user communications unit is arranged for monitoring and recording activities instigated by a user when using the services supported by the server system, and for playing back such recorded activities.

Such methods and apparatus allow various aspects of a server supported system to be tested and investigated. In particular, it is possible to simulate heavy usage of the system and investigate how the system behaves. Such testing may be termed load testing and might be used to establish the effect of say 1000 or 10000 users simultaneously attempting to use a web site. There is an advantage in the above defined system because the activities run in the test can reflect the activities of real use rather than artificial test sequences.

The monitoring and recording of activities may be performed in accordance with any of the eighth to eleventh aspects of the invention.

It will be appreciated that playing back of recorded activities refers to the apparatus itself, under the control of suitable software, running through any and all steps instigated by a user when the recording was carried out.

In developments of the twelfth and thirteenth aspects of the invention, activity associated with the service may be monitored during the play back of the recorded activities. This monitoring may be carried out in substantially the same way as defined in any of the relevant aspects of the invention defined above. In particular, the activity may be monitored at each communications unit and sent to the central unit. In this application "activity" /"activity instigated by the user" includes actions directly carried out by the user such as "clicking" of a mouse on an icon and actions carried out by the system without the user being directly involved, for example, data being sent and/or received. In practice activity will typically comprise a stream of occurrences consisting of actions taken by the user and events taking place within communications unit. The methods may comprise the further step of analysing the data obtained during the monitoring step. The apparatus may be arranged for analysing monitored data. The analysis may comprise filtering the data so that it can be presented in a more convenient form. One or more filter rules may be specified for use in the filter process. The or each filter rule may define a standard event which comprises a predetermined set of occurrences . One or more filter rule may specify at least one parameter, values for which are to be extracted from the predetermined set of occurrences. The filtered data may be presented in terms of standard events and associated values. Preferably the analysis is carried out at the central unit. The term end user communications unit is used broadly in this application and should be taken to include conventional computers including PCs, interactive television based systems, landline and mobile communications (telephone) based systems and any other such system which is able to receive information provided across a network. The system may be used with units operating in accordance with WAP (Wireless Application Protocol).

The central unit to which monitoring information is sent is generally distinct from any server supporting services which are to be monitored. The central unit may belong to an organisation which is interested in gathering its own performance information or to an organisation administering the performance monitoring system on behalf of customers. Information collated at the central unit may be accessible via a web site. Customers may be allowed access to information at the central unit which relates to the services which they supply. The central unit may comprise a plurality of devices, for example servers, operating in parallel. In some embodiments more than one central unit may be provided. The network over which services are provided typically comprises an intranet and/or the Internet. The services provided are typically accessible via the World Wide Web. Thus the services are typically accessible via a web site. A user's communications unit may run a browser. The browser may be a generally available browser such as MS Internet Explorer or Netscape Navigator. Alternatively a dedicated browser may be provided. The browser may be an embedded application in, for example, a WAP communications unit.

Any one or any combination of the monitoring, outputting, recording and play back functionality at the communications unit may be facilitated by an applet. Preferably the applet runs in a language which is cross-platform. This facilitates the system functioning on a large range of different end user communications units. The applet may be confined in an environment such that the applet's access to the end user's communications unit is restricted. This can significantly enhance security.

In this application the term applet is used broadly to mean an application which runs within a browser. The applet may be in any appropriate language, for example Java and/or JavaScript. However, use of the term applet should not be taken to specifically imply that the applet is written in/runs in Java. The applet may be persistent or non-persistent. Thus, the applet may be resident in the browser at all times so that activity relating to all pages is monitored or the applet may be associated only with certain web pages so that only activity in relation to such pages is monitored. In the persistent case the applet is installed, at the communications unit, by a user or system administrator. In the non-persistent case the applet is loaded and deleted, at the communications unit, as a page is visited and left respectively. The communications unit may receive the service via a proxy server. Proxy servers are well known in the art of computer networks, basically, the proxy server is sited between the end user and the remainder of the network and traffic in both directions passes through the proxy server. The proxy server may be arranged to insert the applet into all pages or selected pages which pass through it on the way to an end user communications unit. The proxy server may act as a central unit, particularly in the issuance of configuration messages and/or the collection of monitoring data. Thus the central unit may be a proxy server. The communications unit may be arranged so that as a page is visited and loaded into the unit, the interactive content of the page is identified. For example, a page may include a button which can be "pressed" by a user and field allowing the input of text. In the identifying step, the unit may identify that the button and text field are present. If the button is pressed or text is entered this action may be monitored and recorded or reported.

The identifying step may include determining information concerning the relevance and/or context of the interactive content. For example, the relevance, context, effect etc of a user entering text or pressing the button may be identified. This information can be associated with any recorded or reported action.

In at least some embodiments any one or any combination of the following may be monitored: start of page load, completion of page load, completion of image or frame load, user input of data starts, user input of data finishes, user data (including details of key strokes, in terms of timing/speed of operation and/or actual keys pressed), hot spot and hyperlink roll-overs, hyperlink selection, mouse position, field selections, browser toolbar usage, next Uniform Resource Locator (URL) selected, user editing field information, user identification (log on name, device, Internet Protocol (IP) address etc.).

The data output and/or sent to a central unit as a result of the monitoring process may be encrypted. Often, certain sensitive data, such as credit card details, may be irrelevant. Thus any such sensitive data may be replaced by arbitrary symbols in the information output and/or sent to a central unit. Timing means may be provided for giving time stamp references to activities. Preferably a universal time reference source is provided at the central unit. In at least some embodiments any one or any combination of the following real time displays or reports may be generated for a site being monitored: number of visitors per unit time, number of new customers, number of customers who ordered, number of customers by location, number of visitors who tried and failed to order, total web site orders, value of total web site orders, usability of web site, apparent speed per customer, typical routes through site, page hot spots or trouble spots, time to complete transaction pair, events by time of day, average/minimum/maximum time to complete transaction, page load time by time of day, time from page load to page exit, exit route from each page, name of user by time of day, IP address of user by time of day.

The or each communications unit may, amongst other things, function as a data capture module. The central unit may, amongst other things, function as a database server.

According to a fourteenth aspect of the present invention there is provided a machine readable medium having thereon code portions which when loaded and run on computer means cause the computer means to execute the method according to any one of the eighth, eleventh or twelfth aspects of the invention and/or provides apparatus according to anyone of the ninth, tenth or thirteenth aspects of the invention.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which:-

Figure 1 schematically shows the architecture of a system for monitoring the performance of services provided over a network;

Figure 2 schematically shows a system for monitoring the performance of a website based service provided over the World Wide Web wherein the monitoring activity takes place within a browser;

Figure 3 schematically shows the steps carried out in monitoring activity associated with a web page in the system shown in Figure 2;

Figure 4 schematically shows a process used to test a server system;

Figure 5 schematically shows internal architecture of a database server; Figure 6 shows an example of data stored in a data log of the database server shown in Figure 5; and

Figure 7 schematically shows the architecture of a system for customer relations management in respect of services provided over a network. Figure 1 schematically shows the architecture of a system for monitoring the performance of services provided over a network.

A plurality of end user communication units 1 which can include conventional computers, interactive television based systems and wireless communication systems etc . , are connected to an intranet or the Internet network 2 and thus are able to access services supported by a large number of different servers 3 (only one of which is shown in Figure 1). A central unit 4 to which data concerning the performance of services provided over the network is to be sent, as will be explained in more detail below, is also connected to the intranet or Internet 2. A customer ' s computer system 5 is connected via the intranet or Internet 2 to the central unit 4 to allow the customer to extract information concerning the performance of services in which he is interested. Although not shown in detail it will be appreciated by those skilled in the art that within the intranet or Internet 2 there will be a number of intermediate devices such as routers, servers and other devices. These are all potentially connectable to the central unit 4 and as such data concerning performance of these intermediate devices may also be monitored and sent to the central unit 4. A simplified description of the functioning of the system is given below. At each of the end user units 1 a user will access a service supported by a web server 3 via the intranet or Internet 2. As this service is used by the user then, under the control of appropriate software, the respective end user unit 1 monitors activities instigated by the user which relate to the service being used. The data obtained during this monitoring step is then sent from each of the end user communication units 1 via the intranet or Internet 2 to the central unit 4. The central unit 4 functions as a database server and performs a number of functions as will be described in more detail below. At this point it is enough to note that all of the data obtained at each of the end user communication units 1 is stored at the central unit 4 and is put into a useful form such that a customer may obtain data concerning the services in which he is interested either in the form of hard copy reports or via his computer system 5 and the intranet or Internet 2. In particular it is envisaged that the customer will operate a web site based service and will desire information concerning the performance of that website.

Each of the end user communication units 1 includes a processor, a memory, and other elements which are arranged under the control of appropriate software to capture data concerning various activities which take place in respect of the service being provided over the network 2. Different pieces of software are provided to give this data capture function in different circumstances. Different pieces of such software will be described in more detail below.

As mentioned above data capture modules can be arranged to collect information from a variety of sources. In particular data can be collected by monitoring activities within a user's browser, from the network delivering data to the user, and from servers hosting the web pages or applications which a user is using and/or running. However, it will be appreciated by those skilled in the art that the collection of data need not necessarily be limited to the above-mentioned sources .

The central unit 4 includes a processor, a memory and other elements which are arranged under the control of appropriate software to act as a database server which is used for receiving, storing, analysing and organising data captured by any of the data capture modules as well as generating reports concerning such data.

Appropriate software is also provided to customers for use with their computer systems 5 in order to further process and interpret the data stored at the central unit 4. In particular it is possible for customers to generate reports, analyse statistics and generate graphs on the basis of the collected data. It should be noted that the methods and apparatus for monitoring and/or testing the performance of services provided over a network which this application concerns may be used in relation to any appropriate service provided over a network. The methods and apparatus are not limited to use with services provided via websites accessible over the World Wide Web. However, for the sake of clarity the remaining detailed description will be phrased in terms exclusively relating to services that are accessible via a website and the World Wide Web. Figure 2 schematically shows a system for monitoring the performance of a website based service provided over the World Wide Web wherein the monitoring activity takes place within a browser such as Netscape Navigator or MS Interned Explorer loaded on a user ' s computer system which acts as a communications unit 1.

In the case shown in Figure 2 the data capture module consists of a user's computer system 1 arranged under the control of a browser and an applet which is resident in each web page that is to be monitored. Applets are small applications written in, for example, the Java and JavaScript programming languages which may be downloaded from a website into a user ' s browser in order to carry out a particular function. The applet used in the system shown in Figure 2 is currently named Prophet by the applicants and this name shall be used in the description to aid understanding.

It will be appreciated that a system such as that shown in Figure 2 can be used to monitor performance of a large number of websites provided at different servers which are connected to the Internet. However, again for the sake of simplicity in this case, a single website and the performance of the service supported by that website shall be considered.

Thus, in this case, a website is supported by a web server 3 which is accessible via the Internet 2. The website has been set up such that the Prophet applet is contained by each web page 101 which is to be monitored. This means that as a user visits a web page 101 the user's browser automatically downloads and executes the applet. Figure 2 schematically shows web pages 101 displayed in the user's browser and the prophet applet 102 running within the page 101.

The user's communication unit 1 under the control of the prophet applet monitors the user ' s interaction with the web page 101 and returns the information obtained to the central unit 4 which in Figure 2 is shown to comprise a database server 41. A customer can obtain information from the database server 41 concerning the performance of the website provided at the web server 3.

Each frame or each web page to be monitored must include a copy of the Prophet applet.

The Prophet applet may be configured to perform a range of different monitoring tasks and to select different types of data. In practice a single version of the prophet applet is made available and included into the appropriate web pages by the author or maintainer of the pages. The configuration is achieved by a configuration message which is sent to the applet from the central unit server 41. Figure 3 is a flow chart schematically showing the steps carried out in monitoring activity associated with a web page in the system shown in Figure 2.

In step 0 a web page and resident Prophet applet is loaded into a user's browser. In step 1 as the applet is activated within the browser an activation notification signal is output under the control of the applet to the central unit server 41.

Each customer (each entity who includes the Prophet applet on their web pages ) is supplied with a registration key. This registration key is used to verify web page 101 and central server 41 match. The appropriate key is included in the applet in each page. A copy of the registration key is included in the activation notification. The central server 41 checks to see that a valid key has been received. If there is some mis-match this could indicate an incorrectly set up page or a hacking attempt. If any such mis-match is determined then any further data received from that instance of the applet is ignored by the central server 41.

The activation notification includes an indication of the instant at which the notification is generated in terms of time as kept by the communication unit 1 concerned. The Prophet applet treats this instant as time zero and all later occurrences a logged relative to time zero. The time of this instant, in communication unit time, is received by the central server 41 and compared to a server universal time. The result of the comparison is used to apply an appropriate offset to subsequent timings received from the communications unit 1 such that all occurrences dealt with at the central server 41 are logged in server universal time.

Correct receipt of the activation notification by the central server 41 triggers issuance of a configuration message, at step 2, which is sent to the respective communications unit 1. The content of the configuration message is selected by the central unit server 41 on the basis of preselected information received by the server 41. In particular, the configuration will depend on the page being loaded into the browser and may also depend on other factors or information such as the IP (Internet Protocol) address or name of the user, the time of day and/or other user or system information.

The first time that an applet in a particular instance of browser sends an activation notification to the central server 41, the resulting configuration message includes a session ID which can be used to identify the origin of each occurrence which is monitored and sent to the central unit server 41. This session ID uniquely identifies the particular instance of browser being used and this allows occurrences relating to a single browser instance to be tied together easily. Further elements of identification may be used to allow the particular page being used to be identified so that occurrences relating to a single page can be tied together easily. The configuration message will typically also include details of the occurrences that should be monitored in respect of that page, these being controlled by the entity who is interested in the data. For example to undertake simple "user path analysis" only page load and unload events are needed. On the other hand, to undertake a detailed analysis of failure modes in a form it is necessary to collect information on mouse movements and keystrokes from the pages in question. In determining the occurrences to be specified in the configuration message, the central unit consults an internal table or process to determine what information the applet should collect from this URL at this time (as mentioned above, the decision on what data to collect can be based on many factors (such as URL, time of day, previous activity, or a random or pseudo random process which will arrange for a specific proportion of pages to have data collected)). It should be noted that this configuration process facilitates the use of a single common applet. At the same time that the applet is signalling its existence in step 1, the contents of the page being loaded into the browser is scanned under control of the prophet applet in step 3. The applet develops a page map which includes a list of all of the page components. This is used to allow the applet to quickly analyse any action taken by the user and prepare a record which correctly contextualises the action. At step 4 a log of occurrences which occur in relation to the web page concerned is generated, each occurrence being given a time stamp relative to zero time. The occurrences logged in step 4 correspond to actions directly taken by the user as well as events occurring in the browser without the user ' s direct involvement.

A large range of different occurrences may be logged. As mentioned above the actual occurrences logged will depend on the contents of the configuration message received by the prophet applet.

Below is a non-exhaustive list of the occurrences which may be monitored and logged: Start of page load

Completion of page load

Completion of image or frame load

User input data finished

User input data started User data (including details of keystrokes, in terms of timing/speed of operation and/or actual keys pressed) Hot Spot, and Hyper Link rollovers

Hyper Link selection Mouse position

Field selections

Browser toolbar usage

Next URL selected

User editing of field information User identification (log on name, device, IP address, etc)

In step 5 any sensitive information such as credit card details may replaced by non specific characters such as asterisks and all data is encrypted. Whether or not information is replaced by non-specific characters will depend on the configuration message supplied to the Prophet applet. In general terms a choice can be made and specified in the configuration as to whether details of characters input are retrieved in respect of any given page or frame. Thus for example, if a page or frame relates to credit card details, a non-specific keystroke option can be chosen which reports keystrokes but not the keys pressed. It can be noted that password fields are recognisable by the Prophet applet and thus the recovery of password characters can be treated differently from the remainder of a frame or page - i.e. password details would almost never be recovered.

At step 6, the information logged at step 4 and encrypted at step 5 is sent via the Internet 2 to the central server 41 for further processing and reporting as will be described in more detail below. In practice data may be allowed to build up to a predetermined level at the communications unit 1 before being sent to the central server 41. Steps 4 to 6 in Figure 3 will run and re-run continually whilst a page is active but it is not necessary for all three steps to be carried out for a given occurrence before processing of the next occurrence begins. An additional sending of data may be made as a page is left to ensure all data has been output.

The scanning operation which occurs in step 3 is described in more detail below. To help understand this operation some background is useful. As will be understood by anyone familiar with current "object oriented" software engineering techniques, all items or components within a web page are "objects". Web pages are coded in HTML (Hyper Text Mark-up Language), this language is composed of "tags" each defining some aspect of the page ( images to be displayed, hyperlinks to be associated with items on the page, text to be displayed and formatting commands (such as font, size, tables, colours etc.)). Each component of the page will consist of one or more objects.

When a user requests to view a page with a Web Browser, a Web Server or Application Server will send the appropriate HTML tags to the user's Browser. The Browser will parse the inbound HTML and construct the page on the screen, at the same time it will construct an internal software table describing all the objects - this table is known as the Browser's "Object Model". The object model provides a mechanism for applets running within the browser to interact with the page, and for the browser to obtain information about and respond to the actions of the user.

Each action the user takes will generate "events" within the object model, for example as they roll their mouse over a picture, the object model will receive a "rollover event" directed to the object representing the picture, or as they click on a link they will generate a "click event" for the object representing the link. In this way every action of the user will result in one or more events within the object model.

In this application, in general terms, the prophet applet selectively collects these events and returns them to the central server 41. In the scanning step mentioned above, as a page is received, the prophet applet scans the object model to understand the structure of the page being displayed, the applet then "registers" with the object model to receive the events it is configured to collect.

This scanning or parsing of the object model means that a single applet is capable of adapting to any page which is downloaded. This is by virtue of the fact that the applet automatically parses the object model for the page it finds itself in, and then registers for all required events from any objects within the object model which are capable of generating one of those events . The fact that a single applet can deal with all pages can provide various advantages . One advantage is the fact that the system and method can become easy to implement. A common HTML applet insertion tag can be inserted into all pages to be monitored and the need to tailor applets to match the page that they are in can be avoided.

Another advantage is that the browser can cache the prophet applet. This means that once downloaded and stored in cache, any further pages needing the prophet applet in this session can retrieve it from the cache.

The use of a generic applet is further facilitated by the activation notification and configuration methodology described above. As has been discussed above, such a system allows data to be collected which gives an insight to user behaviour and user perceived performance in relation to particular web pages. This information can be used to help to improve the performance or effectiveness of services provided via web pages .

An alternative data capture module is implemented by use of a browser plug-in currently called Vigilante by the applicants which functions in a similar way to the prophet applet but is permanently resident in a user's browser. Thus, in a Vigilante based system, rather than the applet being downloaded onto a user ' s communication unit each time a web page is loaded, Vigilante is always present in the user's browser and thus can be used to monitor a user's interaction with any web pages visited. This can be achieved either by the Vigilante plug-in directly monitoring a user's activity or by it being arranged to load the prophet applet into each downloaded page. The Vigilante plug- in is typically included in the user's browser by the user or the user's system administrator. The Vigilante plug-in may be used for monitoring activity in a similar way to as the Prophet applet discussed above but also may be used for security purposes. For example, an Internet Service Provider may offer an incentive to its users to use Vigilante whilst logged on through their service or an employer may use it to monitor activities being carried out by his or her employees . Although the terms applet and plug-in are used herein to aid understanding, it should be noted that when used in its broad sense, the term applet encompasses plug-ins.

As a further alternative a dedicated browser may be provided in which the Vigilante or prophet functionality is incorporated. The dedicated browser may be used in substantially the same way as existing browsers such as Netscape Navigator and MS Internet Explorer, whilst at the same time providing the monitoring functions discussed above. The browser might be used by a user or a customer to monitor and/or control a user's activity. This may be useful for organisations to retain a certain level of control over staff's access to the intranet or Internet or at least monitor their activities. In such systems it may be preferable to provide a configuration signal from a local server or stored cookie rather than from the central unit server 41.

As a further alternative a proxy server could be provided with the ability to insert the prophet applet (or other client side adapter = CSA) into the web data being viewed (e.g. HTML). Thus the applet (client side adapter) will be inserted by the proxy into every page (dynamically) during the data's journey through the proxy server. In this way all browsers which access data through this proxy will have their interaction monitored, with data being sent back to the proxy server. The proxy may then forward this data on to another machine or may store it itself for later analysis.

Of course the proxy server may instruct the applets (CSAs) to only collect data in certain circumstances or indeed only insert the applet (CSA) under specific conditions.

This functionality would be useful in a corporate environment where the ability to monitor and control employee's internet use is desired. In this case the proxy in question would be a server or servers which serve data to employees . More specifically this machine may also act as the corporate firewall, it being the obvious choice for this technology as a firewall already controls data flow to the internet/intranet.

Further a web portal (or similar gateway service) may make use of this technique to monitor client behaviour on behalf of web service providers (e.g. corporate clients).

Data concerning network and server operation may also be monitored by the provision of suitable software. The exact method for monitoring such data will depend on the devices being monitored. However, the use of a configuration message and the use of server universal time is preferable. Further, the data extracted is preferably returned to a central unit for further processing. In a further developments, a server supported service testing and in particular a load testing tool is provided. The testing system uses the same general architecture as is shown in Figure 1. Figure 4 schematically shows the process used to test the server based system.

Initially one or more users is allowed to use a service supported by the server 3 which is to be tested, and whilst doing so their activity is monitored in step 100 using the prophet or Vigilante systems described above. This monitored activity is then recorded as a script in step 101. In step 102 one or more scripts recorded in step 101 are replayed by end user communication units 1. Typically a large number of scripts will be run on separate end user communications units 1 to simulate the effect of the service experiencing heavy usage. In step 103, as the scripts are replayed the performance of the service is monitored from the point of view of each user, ie at each end user communications unit 1. The second monitoring step 103 is again substantially the same as that described above in relation to the Prophet applet and Figures 2 and 3. At step 104 the data gained in the monitoring step is sent to the central unit 4.

Suitable software for controlling the running of scripts and monitoring of behaviour is provided at each communications unit 1. Although this may be implemented in a number of different ways it will be most efficient to use applets or plug-ins substantially the same as the Prophet applet and Vigilante plug-in described in detail above. The software used to implement steps 102 to 104 shown in Figure 4 above is currently called Slayer by the applicants and this term will be used below to ease understanding. When Slayer is run on a end user communication unit 1 it announces its presence to the central unit server 41 and awaits further instructions. Further instructions are issued via the central server 41 typically under the control of a systems manager in charge of the server based service to be tested. The necessary user communications units 1 are activated, for example by a systems manager or an automated system, and caused to load a particular web page. Once this has been done interaction with web pages is governed by the recorded scripts which may be downloaded from the central server 41 to the user communication units 1 concerned. It is to be noted that the scripts to be replayed by Slayer can, and preferably should be recordings of activities carried out by actual users. Thus recorded scripts are likely to include mistakes, incorrect entries, invalid transactions and perhaps arbitrary delays or hesitations. This can give a much more accurate representation of real world traffic.

However, although the scripts are typically recordings of real users and can be used to accurately re-create the actual steps taken, the scripts may be replayed at high speed and/or multiplied to give the effect of many users simultaneously attempting to use the same system. All factors concerning the rate at which data is entered and the time between each transaction etc. may be controlled by the system manager to give the desired test circumstances.

A further advantage of this system over one which relies on artificially generated test programs is that when web page designs are changed, scripts relating to the amended pages can be automatically generated as users use those new pages. If a Prophet or Vigilante based system is being used in relation to the pages concerned there will be a ready made source for recorded scripts. The need for manually re-generating scripts for each version of the site can therefore be avoided.

In some circumstances it may be appropriate and preferable to edit the recorded scripts before they are replayed by Slayer. For example, this might be necessary to prevent real purchasing transactions occurring during replay.

The following are examples of browser events which may occur as the user interacts with a page. In each case these events may be associated with scripts. This means that such events may be monitored using the Prophet or Vigilante system mentioned above and also may be re-run using the Slayer system. Load:- occurs when all the content of a particular document has been loaded within a page.

Unload:- occurs when a document is removed from a window or frame.

Abort:- occurs when page loading is stopped before an image has been allowed to completely load. Error:- occurs when an image does not load properly or when an error occurs during script execution. Select:- occurs when a user selects some text in the text field.

Focus:- occurs when an element receives focus via a pointing device or tab navigation.

Change:- occurs when part of a page such as an input region or a text area loses focus and its content has been changed since gaining focus.

Submit:- occurs when a form is submitted. Reset:- occurs when a form is reset. Blur:- occurs when an element loses focus. Resize:- occurs when a document view is resized. Scroll:- occurs when a document view is scrolled. The arrangement of the present systems give advantages in that aggregate computing power of a large number of end user communication units may be used in the gathering of data and or the running of scripts to provide a load testing function. This limits the amount of processing power required at the central server 41 and facilitates the gathering of information which is specific to individual end users. To maximise the advantage of this distributed processing effect the format of the data sent to the central server 41 should be such that as little processing as possible is required on the data received at the server.

Although the system is such that data can only be gathered in relation to pages in which the applet is active, it is possible to gain information about what happens to cause the page to be exited. Typically this may be movement to another page or website. The applet may monitor and log the identity of the next site to be visited and also the event which caused such a move, for example a mouse click on a hypertext link or the direct entry of a URL. In some circumstances it may be necessary for the applet to be signed using a signature technique which is applicable across all compatible browsers. The authority granted by the certificate should be sufficient to accomplish tasks required for monitoring and logging data. Thus the certificate is preferably sufficient to allow access to all entities within the HTML frame, to obtain access to sub-windows opened by the browser or any contained scripts, and optionally to access the browser buttons and menu activity. If a signed applet is received by an end user communication unit 1 this version of the applet may be retained by the end user communication unit and used for subsequent pages.

Figure 5 schematically shows the internal architecture of the database server 41 supported by the central unit 4. The database server comprises a data packet receiver/generator 6 which is arranged to output and receive data to and from any data capture module. The data packet receiver/generator 6 facilitates communications between the data capture modules and the database server 41. Amongst other functions, the data packet receiver/generator 6 receives activation notices from data capture modules and returns configuration messages. The database server 41 further comprises a system maintenance module 7 which provides tools and mechanisms for defining configuration rules for the different versions of data capture modules which are in existence. In relation to the Prophet applet this allows the generation of configuration settings for use with the different instances of the Prophet applet which have been included in web pages by customers. The tools provided by the systems maintenance module 7 also allow systems managers to populate and manage an originator ' s database 8 which holds configuration data for all known data capture modules, i.e. all known versions of the Prophet applet amongst other things. The originator's database 8 constructs and issues configuration messages based on the activation notifications which it receives from remote data capture modules via the data packet receiver 6. The system maintenance module 7 also provides configuration and maintenance tools for the other functions of the database server 41 described below.

The database server 41 includes a data log 9 which holds all the data collected from the data capture modules. Each entry in the data log includes details of the occurrence and a time stamp indicating when the occurrence was lodged in the data capture module. The data log 9 also adds a time stamp indicating the time at which it logged the occurrence. Figure 6 shows an example of the data stored in the data log 9.

As well as data from user browser based data capture modules, the data log 9 also logs utilisation data from data capture modules provided in the network 2 and at servers. Utilisation data will include statistics such as server CPU (central processing unit)utilisation, memory utilisation and network bandwidth usage. Thus this information is of a more generic data than that obtained directly from a user ' s browser.

The database server 41 further comprises a standard event and utilisation filter module 10 which is used to process the data stored in the data log 9 in order to reduce its volume and present it in a more usable fashion. The standard event and utilisation filter module 10 uses filter rules stored in a filter rule database 11.

A rule wizard system 12 is provided to allow a systems manager to generate filter rules. A filter rule is used to define standard events which are characterised by a sequence of one or more occurrences taking place in a given sequence within a single browsing session. As described above, an occurrence is constituted by any action carried out by the user or any event within the browser however minor. A collection of data concerning such occurrences is not always useful. The generation of filter rules defining standard events allows the data to be put in a much more usable and compact form. The rules wizard system 12 allows a newly generated filter rule to be tested against a portion of the data stored in the data log 9 to test its function. Once a rule has been tested it can be stored in the filter rule database 11.

Each filter rule can have active or inactive status . This means that not all rules which have been generated must be applied to all incoming data. All data stored in the data log 9 is parsed by all active rules specified in the standard event and utilisation filter module 10.

Each filter rule assigns a name to each standard event and may also specify one or more associated value, such as an elapsed time, an absolute time, or other data to be retrieved from the specific occurrences making up the standard event.

The standard event and utilisation filter module 10 holds a state table for each rule in an active browsing session. Whenever the rule state table signifies that a standard event has occurred, a corresponding event record is written into a standard event log 13. The standard event record includes a time stamp taken from the final occurrence which triggered the standard event creation. Moreover, any additional data specified by the rule will be inserted into the standard event record.

Rules may also be defined using the rule wizard system 12 to identify utilisation events. A state table is held in the standard event and utilisation filter module 10 for each utilisation event rule. Whenever the utilisation event rule state table signifies that a utilisation event has occurred, a utilisation event record is written into a utilisation log 14.

The standard event and utilisation filter module 10 also has the function of calculating real time statistical information which it stores in a real time statistics database 15.

Data from the real time statistics database 15 is fed to a real time display module 16 which displays real time statistical data on the performance of websites which are being monitored. The type of information which is provided by the real time display module 16 is high level and thus, for example, might include number of sales per second.

A graph generation module 17 is provided to generate graphs from the data stored in the standard event and utilisation log 13,14. These graphs may be made available via suitable web pages and can represent historic or near real time information. A graph may for example show data concerning the different times taken to load a given page on a web site. The system includes a facility such that by appropriately selecting points on a graph, the detailed standard event record may be viewed for that or those points. Furthermore, it is possible to display all occurrences which resulted in that standard event.

Tools provided in the systems maintenance module 7 as well as the functionality of the real time display module 16 and graph generating module 17 allow the production of ad hoc reports by customers who are having their web sites monitored. Although Figure 5 shows the generation of graphs and ad-hoc reports from filtered data, it should be noted that raw data from the data log 9 can also be used in the generation of graphs, ad-hoc reports and in any other ways desired by a customer.

It is not essential for customers to gain performance information directly from the central unit 4. Reports may be generated by the administrators of the monitoring system and provided to customers . Such reports may, for example, be in the form of hard copy or sent electronically.

The database server also includes a session replay module 18 which allows the replay of any session stored in the data log 9. Thus the functionality of the session replay module 18 is similar to, but distinct from, that supplied by the Slayer system described above. The session replay module 18 functions by retrieving all the HTML code stored in the data log 9 and optionally loading any unstored data such as images from the Internet. The module 18 then replays the actions taken by the user. This replay includes redisplaying the pages visited and user interaction therewith. Thus this module gives the ability to review the actions carried out by a particular user which may be useful in identifying a problem which occurred either to assist the user in overcoming the problem or to highlight an aspect of the web page or web site which may be improved. The redisplay may be allowed to run as a real time "virtual video" or may be used to review certain parts of an interaction sequence. Thus, for example, some portions may be run at a higher speed, i.e. fast forward, whilst other portions may be redisplayed in slow motion, or even stepped through. Any portions of particular interest may be run through several times . The systems described above are capable of providing information concerning uses of web sites which is extremely detailed. For example it is possible to provide real time displays and or reports showing the following amongst other things : Number of visitors per unit time, Number of new customers, Number of customers who ordered, Number of customers by location, Number of visitors who tried and failed to order, Total website orders,

Total website order value, Website navigation, Usability of website, Apparent speed per customer,

Typical route through site,

Page hot spots,

Time to complete a standard event, Events by time of day,

Average and maximum/minimum time to complete transaction,

Page load time by page by time of day,

Time from loading to exit of page, Exit route from page,

Name of user by time of day,

IP address of user by time of day.

It is envisaged that such and other data will enable organisations running websites to optimise their services. In particular it is envisaged that it may be possible to reduce cost of providing the service, maximise revenue/transaction rate, highlight and investigate failure modes, understand usability of site, detect unsatisfactory service, detect and correct site design issues, undertake detailed analysis of user behaviour, evaluate success of investments in technology, target IT investment strategies for e-commerce applications.

The following gives an example of the kind of advantages which using a system of the current application can give.

A website owner may be experiencing a large number of incomplete transactions and also retrieving complaints of poor performance from their customer research. By including the Prophet applet on each relevant page of their website and configuring the system to retrieve time of day information on the entry and exit from each page as well as recording the exit routes from each page the following type of information may be gained. For example the time taken by users to complete some key pages may be identified. For example it may be determined that whilst 50% of users complete a page in less than 20 seconds nearly 20% take more than 2 minutes, whilst 20% never complete the transaction. By more careful analysis of the data it may become apparent that a large proportion of the slow users are using the same Internet service provider and this can indicate that there are problems using this Internet server provider. However, there may be some other reason whilst the other users are having difficulty. It might, for example, be established that a high proportion of users are having to access the help page more than twice whilst attempting to complete the transaction. This could point to a problem in the page design. Moreover, it might be established that a significant proportion of customers begin to fill out a user registration form but fail to complete it.

This could suggest that the registration form is too long or too complex. It might alternatively be found that a large number of users leave the site via a banner advert provided on one of the pages . It may then be concluded that the positioning of the advert is disadvantageous.

As another example, it is highlighted that cursor/mouse position within a page can be monitored. This can be used to generate statistical data on cursor position. This in turn can assist in page design, it might for example, be established that a majority of users seem to be attempting to find the "submit" button in the bottom right hand corner of a page even though the button is located elsewhere.

In general terms it will be appreciated how the information provided by systems described in the present application can be of great assistance in improving website design.

In alternatives a rules wizard may not be included but rather rules may be generated and programmed manually.

From the above it will be realised that the systems, methods and apparatus of the present application may be used for purposes other than monitoring the performance of services. In general a facility for extracting data concerning the use of services by users is provided. This extracted data may be put to a number of different uses. Some specific features of the system (client side and server side) and uses to which it may be put are detailed below.

The basic applets provided are generic and have the ability to trap and report events in respect of all objects within a page. Thus even if a page changes the applet will continue to function. The applet may be set up to track events which relate to specific objects within the page.

True web enabled replay is possible based on the information gathered at the server. This can include activities of other applets active within the page. It is also possible to generate site maps from the data retrieved showing the paths followed by actual users through a site being monitored. This can be compared to original site design documents. A "most used path" can be determined.

Various real time functions can be provided as outlined below.

When the system's applet is provided at a given website, and this site is being used, the central unit server 41 will see incoming information. There will often be a pattern to this incoming information, for example, if the site is busy, data from the associated applet(s) will be received almost continuously. The central unit server 41 may be arranged to output an alarm if data is not received at the minimum frequency expected as absence of incoming data can be indicative of the site being broken. Similarly, an alarm may be raised at the central unit server 41 if it is determined that the site is running too slowly.

Attempts to hack into a site being monitored may also be detected and an alarm raised. The data received at the central unit server 41 is such that, typing rates which are too fast or too consistent to be human generated can be detected and treated as an indication of a robot typer. Repeated typing of control codes can also be noted and treated as an indication of a hacker looking for a "back door".

Similarly, an alert can be raised if an unrecognised object is detected since this might be a "back door" object being inserted.

Customer relations management (CRM, or eCRM in the present context) is a further particular use to which data captured by the above systems can be put. In particular, data received at the central unit server 41 may be used to facilitate the personalization of services, for example the content of webpage, provided to individual users. The present systems allow real time personalization.

Figure 7 schematically shows the architecture of a system which can be used in methods of customer relations management in respect of services provided over a network, in particular for the real time personalization of a website being visited by a user. The basic architecture and functioning of this system is similar to that described above in relation to Figures 1 to 3, 5 and 6 and thus comprises a plurality of end user communications units 1 (only one of which is shown), connected via an intranet or the Internet 2 to a plurality of web servers 3 (only one of which is shown) and a central unit 4 including a server 41. For the sake of brevity and clarity, the same reference numerals are used for the corresponding parts of this system and that described above with particular reference to figures 1 to 3 and detailed description of the functioning and operation of the system of Figure 7 is omitted where this is substantially the same as that described above or where any modifications required are clear.

The particular addition in the present system is a personalization engine 200 which is connected to the central unit server 41 and the web server 3 which supports the service to be personalized. In the same way as described above, a Prophet or Vigilante applet 102 running in the webpage 101 being viewed by a user captures information concerning the user's interaction with that page and sends this information to the central unit server 41. The central unit server 41 passes selected information onto the personalization engine 200. At the personalization engine 200, the received information is processed and a determination is made as to whether the website being accessed by the user should be modified in view of the reported information. If it is decided that a change should be made, the personalization engine 200 sends appropriate instructions and/or new pages/objects to the user via the web server 3 so that the user viewing the site experiences the modification whilst still interacting with the site.

It is important to realise that the present system is such that information concerning specific user interaction with a website can be passed to the personalization engine 200 in real time and an appropriate change can be made to the site, and in particular the page being viewed, in real time. As such, if desired, the applet 102 and central unit server 41 can be arranged to transmit the appropriate information more rapidly than might be the case for some other uses of data mentioned above.

As an example, the pages which a user has viewed, the fields which a user has completed, and the time for which the user has had his cursor hovering of a particular portion of a page may be reported. Based on this information the personalization engine 200 may, for example, determine that the user is seriously considering purchasing an item. In view of this, the personalization engine 200 may cause a new banner to be displayed to the user on the viewed page or a new window to open giving details of a special offer relating to that item. The offer might be designed to induce a purchase, for example a 10% price reduction might be offered for purchases made within 10 minutes of the banner being displayed. In other examples, the system might be used to offer suggestions, advice, or assistance to a user which is determined to be of relevance to that user, at that time, because of their actions and perhaps other knowledge of the user. In the present system, the operation of the applet resident in a web pages is substantially the same as described above. The contents of a configuration message sent to the applet on initiation as described above with reference to Figures 2 and 3, determines the information which a specific instance of an applet is arranged to collect and report. This ensures that the system can use generic rather than dedicated applets with different sites. For the present system, information which is important for customer relations management will be amongst that specified. The operation of the central unit 4 in the present system is typically slightly different from that in the systems described above. In particular, information concerning occurrences classified as important for personalization purposes is passed immediately from the central unit 4 to the personalization engine 200 rather than being stored or subjected to any statistical operations. In the present embodiment, the central unit 4 analyses the information received from the communications units 1 to identify the information to be forwarded to the personalization engine 200. Of course the system is flexible so that type of data to be forward to a given personalization engine can be specifically chosen. In alternatives, rather than performing the analysis to identify the information to be forwarded at the central unit 4, all data captured concerning a particular site may be sent to the personalization engine 200 for analysis.

In a further alternative, the central unit 4 may be arranged to look for predetermined sequences of occurrences chosen because of their particular relevance to the personalization engine 200 and to output the corresponding data when the sequences are detected. In this way, a stream of data relating only to preselected sequences of occurrences, chosen because of their particular relevance, can be forwarded to the personalization engine 200.

In a further and preferred alternative, the applet responsible for capturing the data may perform pre-processing of the data. In particular, the applet may be arranged to look for the predetermined sequences of occurrences mentioned above. In this way, the most relevant data can be forwarded to the personalization engine 200, whilst making use of distributed processing power provided by each end user communications apparatus 1.

In further alternatives the particularly relevant data may be flagged and sent to the personalization engine 200 along with other less relevant data.

In the system and method described above, the central unit 4 is shown to be distinct from the personalization engine 200, however, in some cases the central unit 4 and personalization engine 200 may be provided at the same location and/or supported by the same computer system. As such the central unit 4 may comprise the personalization engine 200.

In the methods and systems described above, the applet instance in any given page may be configured upon receipt of a configuration message to monitor and report on selected occurrences . The passage above concerning personalisation briefly mentions the idea of the applet carrying further processing of information before reporting to the central unit. In an extension to all of the above systems and methods (not just personalisation), applets which have heightened processing capabilities, currently called "smart applets" by the applicants may be provided. Such smart applets are arranged so that, once appropriately configured, they can undertake processing before returning information to the central unit server. In this way the smart applet may be configured to watch for a particular sequence of events (as mentioned above in respect of personalisation) before responding to the server. Optionally, the smart applet may be arranged and configured to supply a message indicating that the specific sequence (or one of a number of specific sequences) has occurred instead of, or as well as, the information monitored itself.

This might be is implemented as follows:

1. The smart applet is written to allow configuration such that it waits for a set of events to occur (perhaps in sequence) before acting. There may also be timing information associated with this sequence.

2. The smart applet is inserted in pages to be monitored, is downloaded into a user's browser and contacts the central unit for configuration information in a way substantially the same as that described above for the prophet applet.

3. At the central unit, a sequence of events to be looked for is specified (based on, for example URL, time, previous activity or other significant events) 4. The central unit sends its configuration message to the smart applet indicating the sequence of events which should trigger a response and supplies an "trigger event name" which the smart applet should return if the required sequence occurs. 5. If and when this sequence of events occurs, the smart applet sends the central unit a message indicating that the sequence has occurred using the trigger event name. The smart applet may also return other information about the user's interaction. A possible sequence of events to be looked for by a smart applet might be: a. A 5 second delay after page loading b. A click on one of three specified buttons c. More than one roll-over event occurring within a specified location on the page within 3 seconds of the button push d. And then a further rollover event of a given object. The use of smart applets can give various benefits. The amount of communication between the server (central unit) and client (browser) is reduced, as only "significant" events are passed back to the server. Further, the processing load on the server is reduced, as the client's machine undertakes the searching for significant sequences, and because the number of received messages is reduced.

Moreover, smart applets can provide selected real time notification of activity within a page, without the user pressing "submit" (for example during the completion of web-forms). This facilitates the webserver proactively sending additional pages or content to assist the user, or to modify future content. A further advantage is that a smart applet can be used as a mechanism to automate web pages without the need for the writing of Javascript - thus simplifying the building of interactive pages .

Claims

1. A method for customer relations management in respect of services provided over a network comprising the steps of: monitoring a user's interaction with a service provided over a network; and modifying the service in response to the monitored interactions.

2. A method according to claim 1 in which the steps of monitoring and modifying are carried out in real time.

3. A method according to claim 1 or claim 2 in which modifications are made whilst the user is still interacting with the service.

4. A method according to any preceding claim which is implemented using a communications network.

5. A method according to any preceding claim in which the service is provided over a network to a plurality of end user communications units and the step of monitoring a user's interaction with the service comprises the step of receiving at a central unit, information obtained at, and output by, a respective end user communications unit.

6. A method for monitoring use of a service provided over a network to a plurality of end user communications units, the method comprising the step of: receiving at a central unit, information obtained at each end user communications unit during monitoring of activity associated with the service, and supplying data based on said information to an engine to allow modification of the service in dependence on the monitored activity.

7. A method according to claim 6 wherein the information is obtained at each end user communications unit under the control of respective applets running within browsers; and the method comprises, before the receiving of information step, the additional steps of: receiving, at the central unit, activation notifications from active applets; and outputting, from the central unit, respective configuration messages to each communications unit from which activation notification has been received, which messages are arranged to configure the respective applets so as to control the information sent to the central unit.

8. A method of operating an end user communications unit for use in a network services monitoring system, the communications unit being arranged to allow reception of services provided over the network and the method comprising the steps of monitoring activity, at the communications unit, associated with a service provided over the network and outputting information so obtained to allow modification of the service to be performed in dependence on the monitored activity.

9. A method according to claim 8 wherein the service is accessed via at least one web, or other electronic, page and the method comprises the further step of identifying the interactive content of a page as the page is visited and loaded into the communications unit.

10. A method according to claim 9 in which the step of identifying the interactive content includes determining information concerning the relevance and/or context of the interactive content.

11. A method according to claim 9 or claim 10 wherein at least some of the information gained in the identifying step is included in the information output by the communications unit.

12. A method according to claim 9 in which the step of identifying the interactive content includes determining information concerning the relevance and/or context of the interactive content and the method includes the further step of associating this contextual information with information concerning monitored activities.

13. A method according to any one of claims 8 to 12 wherein the monitoring step comprises monitoring for a predetermined sequence of occurrences associated with the service and the outputting step comprises outputting information over the network to a central unit when the predetermined sequence of occurrences is detected.

14. A method according to claim 13 wherein the predetermined sequence of occurrences is operator definable.

15. A method according to claim 13 or claim 14 in which the information comprises a message indicating the detection of the predetermined sequence.

16. A method according to any one of claims 13 to 15 in which the information comprises data concerning the occurrences themselves.

17. A method according to any preceding claim in which the service is accessed via one or more electronic page, such as a web page.

18. A method according to claim 17 in which the information obtained during monitoring comprises details of a user's interaction with an electronic page.

19. A method according to any preceding claim when dependent on any one of claims 8 to 18 in which the monitoring and outputting steps performed at the end user communications unit are facilitated by an applet which runs within a browser and runs in a language which is cross-platform.

20. A method according to any preceding claim when dependent on any one of claims 8 to 19 in which the information is pre-analysed at the respective communications unit.

21. A method according to any preceding claim in which information gained in the monitoring step is forwarded to a personalization engine which is arranged to determine appropriate changes to the service based on the forwarded information.

22. A method according to any preceding claim in which the step of modifying the service comprises the step of changing at least one electronic page associated with the service, preferably whilst the electronic page is being viewed by the user.

23. An end user communications unit for use in a network monitoring system, the communications unit being arranged to allow reception of services provided over the network, being arranged to monitor activity associated with a service provided over the network and being arranged to output information so obtained to allow modification of the service to be performed in dependence on the monitored activity.

24. A network services monitoring system comprising: a plurality of end user communications units, each unit being arranged to allow reception of services provided over a network, being arranged to monitor activity associated with a service provided over the network and being arranged to output information so obtained, and a personalization engine which is arranged to receive information obtained at, and output by, the end user communications units, and to determine appropriate changes to the service provided to each user based on the received information.

25. A computer program comprising code portions which when loaded and run on computer means cause the computer means to execute a method according to any one of claims 1 to 22.

26. A computer program comprising code portions which when loaded and run on computer means constitute apparatus according to claim 23.

27. A computer readable medium having thereon code portions which when loaded and run on computer means cause the computer means to execute a method according to any one of claims 1 to 22.

28. A computer readable medium having thereon code portions which when loaded and run on computer means constitute apparatus according to claim 23.