WO2014118548A1

WO2014118548A1 - Tracking system

Info

Publication number: WO2014118548A1
Application number: PCT/GB2014/050254
Authority: WO
Inventors: Jayesh Ramesh PATEL; Alex CAMBELL; David Charles JENNINGS
Original assignee: Imimobile Europe Ltd
Priority date: 2013-01-30
Filing date: 2014-01-30
Publication date: 2014-08-07
Also published as: GB2510343A; GB201301654D0

Abstract

The present invention provides system for tracking a user accessing an Internet resource on a content server that comprises an encoder arranged to generate an encoded URL comprising information related to a user ID, with the encoded URL pointing to a tracking server. A mechanism is provided for sending the encoded URL to a client device of the user. The client device receives an indication from the user that the user wishes to visit the encoded URL, and sends a request to the tracking server. On receipt of the request from the client device, the tracking server is arranged to obtain the information related to the user ID of the user from encoded URL, and to redirect the browser of the client device to a URL on the content server corresponding to the predetermined resource.

Description

Tracking System

Description

The present invention relates to a tracking system and method. More particular, the present invention relates to tracking a user's access of an Internet resource, e.g. an online or on-device resource.

There are many reasons why it may be desirable to track user's access to an Internet resource (e.g. a particular web page) over the Internet, and there are various ways of doing this.

It will be appreciated that, using the Hypertext Transfer Protocol (HTTP), when a user of a client device desires to access a web page on a content server, the user of the client device may access a hyper link on a web browser on the client device. The web browser of the client device will then send an HTTP request to the content server requesting the web page.

It will be appreciated that such an HTTP request would contain the IP address of the client device. Hence, the content server can store IP addresses of those IP addresses that accessed certain web pages stored on that content server. However, tracking by IP address alone is not satisfactory for a number of reasons. For example, many users of home broadband connections are assigned dynamic IP addresses, meaning that the client device's IP address will change periodically. Furthermore, the same IP address will be applied to all the client devices sharing the same Internet (e.g. household broadband) connection. Hence, tracking by IP address does not distinguish between different users connected to the same Internet access point. In addition, a mobile client device is likely to connect to the Internet via a variety of different means. For example, a typical smartphone user may access the Internet via their operator network (where one set of dynamic IP addresses maybe assigned), their home WiFi network (where another set of dynamic IP addresses may be assigned), and via any number of public WiFi hotspots (each with their own IP addresses). Hence, tracking by IP address is not suited for tracking user actions from mobile client devices. It will also be appreciated that cookies can be used to track users. For example, a content server may use a cookie to determine that a client device has visited a particular web page on that content server before. Cookies provided by the content server of a web page are referred to as first party cookies. Furthermore, third party cookies can be used to track user's across multiple content servers.

There are, however, several issues with tracking cookies. One issue is that the cookie is stored by the web browser on a client device. Therefore, a user using several browsers (e.g. a web browser on a mobile device and on a home PC) would not be tracked accurately.

Another issue is that, due to privacy concerns, there are regulatory pressures in some jurisdictions to limit the use of tracking cookies. Furthermore, privacy concerns can lead to many users turning off cookies (e.g. using a "private browsing mode"). Users can also clear all the cookies stored in the browser.

In addition, a cookie provides a way of providing information about previous browsing history to the server. In the context of a first party cookie, if a user receives a link to a content server that they have not visited before, there will be no first party cookie associated with that content server on the user's client device. Hence, in the context of a first visit by that user to the content server, the first party cookie will not provide any tracking data to the content server.

The present invention sets out to provide a system and method for tracking users' actions that overcomes many of the disadvantages mentioned above.

According to an aspect of the invention, there is provided a system for tracking a user accessing a predetermined resource on a content server, comprising: an ID datastore comprising a user ID relating to the user; a URL datastore comprising a URL corresponding to a predetermined resource on a content server; an encoder arranged to generate an encoded URL comprising information related to the user ID, the encoded URL pointing to a tracking server; a mechanism for sending the encoded URL to a client device of the user; wherein the client device comprises a browser, the client device being arranged to receive an indication from the user that the user wishes to visit the encoded URL, wherein on receipt of said indication the browser of the client device is arranged to send a request to the tracking server; wherein on receipt of the request from the client device, the tracking server is arranged to obtain the information related to the user ID of the user from encoded URL, and to redirect the browser of the client device to a URL on the content server corresponding to the predetermined resource. The predetermined resource can be Internet resource, e.g. an online or on-device resource.

As a result of the above, the fact that the user accessed the predetermined web page can be tracked. This tracking method requires no prior knowledge about the user, except for the user ID (which could be any information identifying the user). Furthermore, as the encoded URL is unique to the user, this way of tracking is independent of the actual client device, browser or Internet connection used by the user to access the

predetermined resource. In other words, this way of tracking does not require any property of the device or any information previously provided to the client device (e.g. stored cookie) to track the user. This way of tracking is also independent of the Internet connection (e.g. IP address) type, location and address.

In addition, because this method of tracking the user's access to the predetermined web page is independent of the means used to access the predetermined web page, the encoded link can be forwarded by the client device to another device of the user, and tracking can still be performed. Therefore, the sender of a message including the encoded URL can accurately track responses (e.g.. page views) associated with those sent messages. Hence, this enables a very effective way of tracking users, with none of the drawbacks of tracking using IP addresses or using tracking cookies.

In some embodiments, the tracking server is arranged to store tracking data indicating that the user with that user ID would like to visit the predetermined resource.

In some embodiments, the encoded URL comprises an URL pointing to the tracking server with information relating to the user ID appended to it.

In some embodiments, the encoded URL is created by using an URL shortening process. In such embodiments, the encoded URL can be created by first creating a long form encoded URL and then using an URL shortening process on the long form encoded URL. In other embodiments, the encoded URL is directly created as a shortened URL. Embodiments that use such an URL shortening process are particularly suited to sending links for tracking to client devices over mobile messaging systems (e.g. SMS) or other services in which message character lengths are limited.

In some embodiments, the encoded URL can contain authentication information used by the tracking server to authenticate the user. For example, the encoded URL may contain information acting as a key, and without this key information present in the encoded URL within the request from the client device, the tracking server may stop processing the request. This can present unauthorised or unwanted access to URLs on the tracking server.

In some embodiments, the URL on the content server corresponding to the

predetermined resource is a second encoded URL.

In some embodiments, the second encoded URL is encoded with information relating to the user ID. In some embodiments, the second encoded URL is encoded with a transaction ID, with the tracking server being arranged to store information relating the transaction ID to the user ID.

In some embodiments, the second encoded URL comprises an URL pointing to the predetermined resource with the information relating to the user ID appended to it. This can be used to facilitate the content server tracking the user, and/or to enable the content server to provide personalised content to the user.

Furthermore, in some embodiments, the second encoded URL may contain

authentication information used by the tracking server to authenticate the user, for example by appending such authentication information to the second encoded URL. This authentication information can be used by the content server to authenticate the user. For example, the second encoded URL may contain information acting as a key, and without this key information present in the second encoded URL, the content server may stop processing the second encoded URL. This can present unauthorised or unwanted access to URLs on the content server.

In some embodiments, the content server is arranged to store tracking data indicating that the user accessing the second encoded URL would like to visit the predetermined resource. In some embodiments, encoded URL is sent to the client device via SMS, MMS or other mobile message platform.

In some embodiments, the user ID is any one or combination of a Twitter handle, user name, customer ID number, or MSISDN. In other embodiments, the user ID can be any information identifying the user.

In some embodiments, the tracking server is arranged to determine device information from the request from the client device, the device information indenting at least one property of the client device.

In some embodiments, the tracking server is arranged to use the device information to determine which URL on the content server corresponding to the predetermined resource to redirect the client device to.

In some embodiments, the second encoded URL comprises information relating to the device information.

Hence, some embodiments can carry out device detection at the tracking server.

Carrying out device detection at the tracking server is associated with a number of advantages. For one it enables content servers to implement redirection to device specific pages without themselves having to carry out any device detection.

Furthermore, it can enable the tracking server to redirect to different content servers based on the device detection. For example, the resource to which the redirection URL redirects may be a proprietary app store. It will be appreciated that two different client devices may wish to access the same content (i.e. a link to a conversion of the same app) on different proprietary app stores. In this example, based on the device detection at the tracking server, the tracking server can redirect the client device to the appropriate propriety app store. This is associated with a number of advantages. It enables tracking to be centrally performed over a number of content servers (who being competitors may not wish to share data), with no modifications required at the content servers.

According to another aspect of the invention, there is provided a tracking server for tracking a user, comprising: a mechanism for receiving a request from a browser of a client device that a user of the client device wishes to visit an encoded URL, the encoded URL relating to a predetermined resource and having been encoded with information related to a user ID of the user; a mechanism for extracting the

information related to the user ID of the user from encoded URL; and a mechanism for redirecting the browser of the client device to a URL on a content server corresponding to the predetermined resource.

In some embodiments, the encoded URL is created by using an URL shortening process. In such embodiments, the encoded URL can be created by first creating a long form encoded URL and then using an URL shortening process on the long form encoded URL. In other embodiments, the encoded URL is directly created as a shortened URL.

In some embodiments, the URL corresponding to the predetermined resource comprises a second encoded URL.

In some embodiments, the second encoded URL is encoded with a transaction ID, the transaction ID being useable by a content server of the predetermined resource to track the user. In some embodiments, the second encoded URL is encoded with information relating to the user ID.

In some embodiments, the second encoded URL comprises an URL pointing to the predetermined resource with information relating to the user ID appended to it.

In some embodiments, the encoded URL is sent via SMS, MMS or other mobile message platform by the tracking server.

In some embodiments, the user ID is any one or combination of a Twitter handle, user name, customer ID number, or MSISDN. In other embodiments, the user ID can be any information identifying the user. In some embodiments, the tracking server is arranged to determine device information from the request from the client device, the device information indenting at least one property of the client device. In some embodiments, the tracking server is arranged to use the device information to determine which URL on the content server corresponding to the predetermined resource to redirect the client device to.

In some embodiments, the tracking server is arranged to obtain the user ID relating to the user from an ID datastore. In some embodiments, the ID datastore is external to the tracking server, and in other embodiments is a local datastore.

In some embodiments, the tracking server is arranged to obtain the URL corresponding to a predetermined resource from a URL datastore. In some embodiments, the URL datastore is external to the tracking server, and in other embodiments is a local datastore.

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

Figure ι shows a schematic diagram of a system for tracking a user accessing a web page according to a first embodiment;

Figure 2 shows a schematic diagram of a client device for use in the system of the first embodiment;

Figure 3 shows a schematic diagram of a tracking server for use in the system of the first embodiment;

Figure 4 shows a flow diagram of the system for tracking a user accessing a web page according to the first embodiment; Figure 5 shows schematic diagram of a system for tracking a user accessing a web page according to a second embodiment; Figure 6 shows a schematic diagram of a client device for use in the system of the second embodiment;

Figure 7 shows a schematic diagram of a tracking server for use in the system of the second embodiment;

Figure 8 shows a flow diagram of the system for tracking a user accessing a web page according to the second embodiment; Figure 9 shows schematic diagram of a system for tracking a user accessing a web page according to a third embodiment;

Figure 10 shows a schematic diagram of a tracking server for use in the system of the third embodiment;

Figure 11 shows a schematic diagram of a tracking server according to a fourth embodiment;

Figure 12 shows a process flow diagram of a system for tracking a user accessing a web page according to the fourth embodiment.

Figure 1 shows a system for tracking a user accessing a web page according to a first embodiment comprising a client device 10, a tracking server 20 and a web content server 30. Each of these is capable of communicating with each other over the Internet via a network 40.

Figure 2 schematic shows the client device 10 in more detail. The client device 10 comprises a web browser 11, an email client 12, a user interface 13, a display 14, and a communications interface 15.

In this embodiment, the client device 10 is a PC used by users A, B and C. For example, the client device 10 could be a home computer connected to a household broadband connection.

The web browser 11 may be a typical web browser, or it could be any other program or application capable of accessing an Internet resource. For example, the web browser 11 could form part of the functionality of an app store app on the client device that is capable of accessing a propriety app store or other Internet resource.

Figure 3 schematic shows the tracking server 20 in more detail. The tracking server 20 comprises an ID datastore 21, URL datastore 22, encoder 23, a message sender 24, a communications interface 25, a decoder 26, and a tracking datastore 27.

The operation of the system of Figure 1 will now be explained with reference to the flow diagram in Figure 4.

In step Si, a user ID relating to a user (e.g. user A) is obtained. In general terms, the user ID could be any information that uniquely identifies user A from other users, e.g. both from users B and C also having access to client device 10, and from other Internet users.

In this embodiment, the user ID is obtained by the tracking server 20, where it is stored in the ID datastore 21. It will be appreciated that the tracking server 20 could obtain the user ID of the user in a variety of ways, as will be discussed in more detail below. In embodiments of the invention, the user ID could be any data that uniquely identifies the user. For example, the user ID could be a MSISDN of the user's mobile device. Alternatively, the user ID could be a Twitter handle, user name, customer ID number, email address or any other data that uniquely identifies the user. In step S2, a URL corresponding to a predetermined Internet recourse on a content server is obtained. For example, this predetermined web page may be a web page that user A is potentially interested in visiting. In this embodiment, the Internet resource is a web page. However, in other embodiments, the Internet recourse may be any an online or on-device resource. For example, the Internet recourse may be content on a propriety app store.

In this embodiment, the URL corresponding to the predetermined web page is obtained by the tracking server 20, where it is stored in the URL datastore 22. It will be appreciated that the tracking server 20 could obtain the URL corresponding to the predetermined web page in a variety of ways, as will be discussed in more detail below. IInn sstteepp SS33,, tthhee ttrraacckkiinngg sseerrvveerr 2200 ccrreeaatteess aann eennccooddeedd UURRLL ccoommpprriissiinngg iinnffoorrmmaattiioonn rreellaatteedd ttoo tthhee uusseerr IIDD uussiinngg tthhee eennccooddeerr 2233.. TThhiiss eennccooddeedd UURRLL ppooiinnttss ttoo tthhee ttrraacckkiinngg sseerrvveerr 2200.. IInn tthhiiss eemmbbooddiimmeenntt,, tthhee eennccooddeedd UURRLL iiss aa uunniiqquuee UURRLL ccoonnttaaiinniinngg aa ccooddee..

55 IInn tthhiiss eemmbbooddiimmeenntt,, tthhee ttrraacckkiinngg sseerrvveerr 2200 oobbttaaiinnss tthhee uusseerr IIDD ooff tthhee uusseerr aanndd uusseess tthhiiss ttoo ccrreeaattee tthhee eennccooddeedd UURRLL bbyy aappppeennddiinngg aa UURRLL ppooiinnttiinngg ttoo tthhee ttrraacckkiinngg sseerrvveerr 2200 wwiitthh aa ccooddee rreellaatteedd ttoo tthhee uusseerr IIDD.. FFoorr eexxaammppllee,, tthhee eennccooddeerr 2233 ccoouulldd uussee tthhee uusseerr IIDD ttoo ccrreeaattee aa uunniiqquuee ccooddee aanndd aappppeenndd tthhiiss ccooddee ttoo aa UURRLL ppooiinnttiinngg ttoo tthhee ttrraacckkiinngg sseerrvveerr 2200.. TThhee eennccooddeedd UURRLL iiss tthheerreeffoorree aa UURRLL tthhaatt iiss uunniiqquuee ffoorr tthhee uusseerr.. IInn ssoommee

1100 eemmbbooddiimmeennttss,, tthhee ttrraacckkiinngg sseerrvveerr 2200 ccoouulldd ssttoorree aa llooookk uupp ttaabbllee ooff uunniiqquuee ccooddeess aanndd ccoorrrreessppoonnddiinngg uusseerr IIDDss..

FFoorr eexxaammppllee,, iiff iitt iiss aassssuummeedd tthhaatt tthhee ddoommaaiinn ooff tthhee ttrraacckkiinngg sseerrvveerr iiss

wwwwww..ttrraaeekkiinnggsseerrvveerr..ccoomm,, tthheenn tthhee eennccooddeedd UURRLL ccoouulldd ttaakkee tthhee ffoorrmm::

1155

wwwwww..ttrraacckkiinnggsseerrvveerr..ccoomm// 22AA55CCGG2244 wwhheerree ""22AA55CCGG2244"" iiss aa uunniiqquuee ccooddee tthhaatt ccoorrrreessppoonnddss ttoo tthhee UUsseerr IIDD..

2200 IItt wwiillll bbee aapppprreecciiaatteedd tthhaatt tthheerree aarree aa vvaarriieettyy ooff wwaayyss iinn wwhhiicchh ssuucchh aa uunniiqquuee ccooddee ccoouulldd bbee ggeenneerraatteedd.. IItt ccoouulldd bbee ddoonnee bbyy ccrreeaattiinngg tthhee ccooddee bbaasseedd oonn aa ccoommbbiinnaattiioonn ooff tthhee oorriiggiinnaall UURRLL aanndd tthhee UUsseerr IIDD ((vviiaa aa hhaasshhiinngg oorr ssiimmiillaarr pprroocceessss)),, oorr ssiimmppllyy bbyy ggeenneerraattiinngg aa rraannddoomm nnuummbbeerr tthhaatt iiss aassssiiggnneedd ttoo tthhee UUsseerr IIDD aanndd oorriiggiinnaall UURRLL iinn aa llooookkuupp ttaabbllee..

2255

FFuurrtthheerrmmoorree,, iinn ssoommee eemmbbooddiimmeennttss,, tthhee eennccooddeedd UURRLL ccoouulldd bbee ggeenneerraatteedd iinn ddiiffffeerreenntt wwaayyss,, aass ddiissccuusssseedd iinn mmoorree ddeettaaiill bbeellooww.. FFoorr eexxaammppllee,, tthhee eennccooddeedd UURRLL ccoouulldd bbee ggeenneerraatteedd bbyy aappppeennddiinngg tthhee UUsseerr IIDD ddiirreeccttllyy ttoo aa UURRLL ppooiinnttiinngg ttoo tthhee ttrraacckkiinngg sseerrvveerr 2200.. IInn ssuucchh aa ccaassee,, tthhee eennccooddeedd UURRLL ccoouulldd ttaakkee tthhee ffoorrmm::

3300

where "4Fd6cc2G" is the User ID of the user.

35 The embodiments of the invention that directly append the User ID to a URL pointing to the tracking server 20 may be appropriate where the User ID is not a publically identifiable ID of the user. For example, if the User ID were the user's mobile telephone number (or MSISDN), then it may not be appropriate for privacy reasons to include the User ID as part of the encoded URL. However, there would be fewer privacy concerns associated with appending a customer ID that has no wider significance.

In some embodiments, the encoded URL can contain other information. For example, the predetermined web page could be associated with a campaign code (stored at the tracking server 20) and this could be appended to the URL on the tracking server 200 along with the user's unique code (or user ID) to produce an encoded URL of the form: vvw^trackingserver.com?ijserx'ode=2A cG24&ca-mpaigncode=4sDFGT

where "2A5CG24" is a unique code that corresponds to the User ID and "4SDFGT" is a campaign code indentifying which predetermined web page the encoded URL relates to.

In some embodiments, the encoded URL can contain other information about the user, such as personal information.

Furthermore, in some embodiments, the encoded URL can contain authentication information used by the tracking server 20 to authenticate the user, as discussed below.

In step S4, the encoded URL is sent to the client device 10. In this embodiment, the encoded URL is sent to the client device 10 by the tracking server 20. For example, the encoded URL could be sent to the client device using the message sender 24, e.g. as a link forming part of an email or other messaging system (such as SMS, Twitter etc). Alternatively, the tracking server 20 may send the encoded URL by another means, i.e. as a link in a web page sent to the web browser of the client device 10.

The client device 10 will receive the encoded URL, and depending on how it is received, it will display it to the user as a link. For example, the encoded URL could be sent to the client device 10 as a link forming part of an email, where it would be displayed to the user on the display 14 using the email client 12. If the user then clicks on this link in the email client 12, the email client 12 will open the web browser 11, causing the web browser 11 to send an HTTP request to the tracking server 20 requesting that the content corresponding to the encoded URL be fetched. If the tracking server 20 sends the encoded URL as a link in a web page sent to the web browser 11 of the client device 10, then the user may click on the link representing the encoded URL in the web browser 11. This will cause web browser 11 of the client device 10 to send an appropriate HTTP request to the tracking server 20.

It will be appreciated that the HTTP request will contain many fields and could contain a variety of different header information. Regardless of the other content of the HTTP request, the HTTP request will contain the encoded URL.

In step S5, the tracking server 20 receives the HTTP request from the client device 10 relating to the encoded URL. The tracking server 20 then decodes the encoded URL, enabling it to obtain the user ID from the HTTP request (step S6) using the decoder 26. In this embodiment, the decoder 26 extracts the unique code from the encoded URL and determines which user ID it relates to. For example, this could be done by looking up which user ID corresponds to the unique code.

If the encoded URL contains other information (e.g. a campaign code), this would also be extracted from the HTTP request. In embodiments in which the encoded URL contains authentication information, then this can be used by the tracking server 20 to authenticate the user. For example, the encoded URL may contain information acting as a key, and without this key information present in the encoded URL within the HTTP Request, the tracking server 20 may stop processing the HTTP Request. This can present unauthorised or unwanted access to URLs on the tracking server 20.

In step S7, the tracking server 20 redirects the client device 10 to a URL on the content server 30 corresponding to the predetermined web page. In this embodiment, the tracking server 20 redirects the client device 10 to the URL of the predetermined web page.

As discussed below, in other embodiments, the tracking server 20 can redirect the client device 10 to an URL that corresponds to the predetermined web page. For example, the tracking server 20 may produce a second encoded URL and redirect the client device 10 to the second encoded URL. The second encoded URL could contain various information either indentifying the transaction and/or identifying the client device 10. Such information could be used by the content server 30 to track users. Then, in step S8, the tracking server 20 stores tracking information indicating that the user accessed the predetermined web page in the tracking datastore 27.

Hence, by using this embodiment, the fact that the user accessed the predetermined web page can be tracked. This tracking method requires no prior knowledge about the user, except for the user ID (which could be any information identifying the user).

Furthermore, as the encoded URL is unique to the user, this way of tracking is independent of the actual client device, web browser or Internet connection used by the user to access the predetermined web page. In other words, this way of tracking does not require any property of the device (e.g. stored cookie) or Internet connection (e.g. IP address) to track the user.

In addition, because this method of tracking the user's access to the predetermined web page is independent of the means used to access the predetermined web page, the encoded link can be forwarded by the client device 10 to another device of the user, and tracking can still be performed. Therefore, the sender of a message including the encoded URL can accurately track responses (i.e. page views) associated with those sent messages.

Hence, this embodiment enables a very effective way of tracking users, with none of the drawbacks of tracking using IP addresses or using tracking cookies.

Figure 5 shows a system for tracking a user accessing a web page according to a second embodiment comprising a client device 100, a tracking server 200 and a web content server 300. Each of these is capable of communicating with each other over suitable networks, In this embodiment, the client device 100 is a mobile device, such as a smartphone. Figure 6 schematic shows the client device 100 in more detail. The client device 100 comprises a web browser 101, an SMS client 12, a user interface 103, a display 104, and a communications interface 105, and a controller 106.

The web browser 101 may be a typical web browser, or it could be any other program or application capable of accessing an Internet resource. For example, the web browser 11 could form part of the functionality of an app store app on the client device that is capable of accessing a propriety app store or other Internet resource.

Figure 7 schematic shows the tracking server 200 in more detail. The tracking server 200 comprises a storage unit 201, an encoder 203, a message sender 204, a

communications interface 205, and a decoder 206.

In this embodiment, the tracking server 200 is in communication with an external ID datastore 210, and an external URL datastore 220.

In this embodiment, the client device 100 is capable of communicating with the tracking server 200 via one of two ways: via the mobile operator 410 or via a WiFi access point 420. It will of course, be appreciated that in practical embodiments, the client device 100 may be able to communicate with the tracking server 200 by any number of different ways, but these two ways are shown for ease of description.

The operation of the system of Figure 5 will now be explained with reference to the flow diagram in Figure 8. In step S11, a user ID relating to a user (e.g. user A) is obtained by the tracking server 200 from the external ID datastore 210. In this embodiment, the user ID is the

MSISDN of the mobile client device 100. It will be appreciated that the MSISDN of the mobile client device 100 is a number uniquely indentifying a subscriber in a mobile network.

For example, the external ID datastore 210 could store a list of MSISDN s that can be acquired as part of a marketing campaign aimed at mobile users. Alternatively, external ID datastore 210 could store a list of MSISDNs provided by users who signed up to a particular promotion as part of a marketing campaign.

In step S12, a URL corresponding to a predetermined Internet resource on the content server 300 is obtained by the tracking server 200 from an external ID datastore 210. In this embodiment, the Internet resource is a web page. However, in other embodiments, the Internet recourse may be any an online or on-device resource. For example, the Internet recourse may be content on a propriety app store. For example, this embodiment could be used as part of a SMS marketing campaign. In such an example, the external ID datastore 210 could store a list of MSISDN s of users that maybe interested in visiting the predetermined web page on the content server 300.

For example, a marketing expert could determine that a category of users (e.g.

housewives with children) might be interested in visiting a promotional page on an e- commerce site. In such an example, the marketing expert might set up the tracking server 200 to obtain MSISDNs of suitable users from the external ID datastore 210 as well as the URL of the promotional page on an e-commerce site. The e-commerce site would act as the content server 300 in this example.

In step S13, the tracking server 200 creates a code related to the MSISDN and the user's desire to visit the predetermined page. For example, the code could comprise a 6 character code in base 62 (giving 62 ^A 6 combinations). The 6 character code could be generated based on the MSISDN and destination URL. Alternatively, a 6 character code in base 62 could be generated at random and then assigned to the MSISDN and the predetermined page in a lookup table. In step S14, the tracking server 200 creates a shortened URL pointing to the tracking server. For example, the shortened URL could correspond to a short link to the domain of the tracking server 200, with the 6 character code appended to it, leading to a shortened URL of the form: http://smrtlnk.com/Ax6dDf where "smrtlnk.com" is a short link to the domain of the tracking server 200, and "Ax6dDf ' is a 6 character code in base 62 that related to the user's MSISDN. The shortened URL therefore is unique to the user.

Hence, the shortened URL in this embodiment is an encoded URL that points to the tracking server 200 as is unique to the user and to the predetermined page. In other words, the shortened URL is tailored to the user ID and to the predetermined page on the content server 30. In other embodiments, an encoded URL (in long form) could be generated, and then a shortened URL generated to correspond to the long form encoded URL. For example, the user's MSISDN and the predetermined web page could be associated with a unique code, with the long form encoded URL being formed by appending the unique code to a URL on the tracking server 200. For example, the long form encoded URL (could have the form: w^w.trackingser ^fer.com?imiquecode=4fliSSijHD where "4fhSSGHD" is the user's unique code.

Alternatively, the predetermined web page could be associated with a campaign code and this could be appended to the URL on the tracking server 200 along with the user's MISISDN to produce an encoded URL (in long form) could have the form: www.trackingserver.com?msisdn=440i2345678& campaigncode=4sDFGT where "44012345678" is the user's MSISDN and "4SDFGT" is a campaign code indentifying which predetermined web page the encoded URL relates to.

Furthermore, in some embodiments, the long form encoded URL can contain authentication information used by the tracking server 20 to authenticate the user, as discussed below. Then a shortened URL could generated to correspond to the encoded URL (in long form) using a known URL shortening process.

In step S15, the shortened URL is sent to the client device 100 as part of an SMS message. In this embodiment, the shortened URL is sent to the client device 100 by the tracking server 200 using the message sender 204. In other words, in step S15, the tracking server 200 sends an SMS message to the client device 100 via the mobile operator network 410.

The client device 100 will receive the shortened URL on its SMS client 102. If the user clicks on the link in the SMS client 102, the SMS client 102 will open the web browser 101, causing the web browser 101 to send an HTTP request to the tracking server 200 requesting that the content corresponding to the shortened URL be fetched.

In step S16, the tracking server 200 receives the HTTP request from the client device 100 relating to the shortened URL. The tracking server 200 then determines from the shortened URL which user (i.e. which MSISDN) and which URL on the content server 300 the shortened URL relates to (step S17). In this embodiment, this is done by looking up which MSISDN and which predetermined URL the 6 character code corresponds to in a lookup table.

In embodiments in which a long form encoded URL is created, which is then shortened, the tracking server 200 can determine this information by reversing the shortening process, e.g. by looking up the appropriate long form URL. If the long form encoded URL contains other information (e.g. a campaign code), this would also be extracted from the HTTP request once the shortening process has been reversed. In embodiments in which the encoded URL contains authentication information, then this can be used by the tracking server 20 to authenticate the user. For example, the long form encoded URL may contain information acting as a key, and without this key information present in the long form encoded URL within the HTTP Request, the tracking server 200 may stop processing the HTTP Request. This can present unauthorised or unwanted access to URLs on the tracking server 200.

In step S18, the tracking server 200 then creates a transaction ID, and then appends the URL corresponding to the predetermined web page with the transaction ID to produce a second encoded URL. In other words, if the URL of the predetermined web page is http://www.contentserver.com, then the second encoded URL could have the form:

where 3x5AAd is the transaction ID. In this embodiment, the transaction ID is information that is unique to the user's request to view the predetermined web page at this time. As discussed below, the transaction ID can enable (optional) tracking to occur at the content server 300. In other embodiments, as discussed below, further information can be appended to the second encoded URL. For example, in some embodiments, the second encoded URL can contain authentication information used by the content server 300 to authenticate the user, as discussed below. In other embodiments, the second encoded URL could contain information about the user or the client device 100.

In step S19, the tracking server 200 redirects the client device 100 to the second encoded URL, which as discussed above points to the content server 300.

Although not shown in Figure 8, in some embodiments, the tracking server 200 can store tracking information indicating that the user accessed the predetermined web page in the tracking datastore 207. In other embodiments, the tracking server 200 need not track the user (and hence would not need a tracking datastore), and all tracking could be done on the content server 300. It will be appreciated that as part of the redirection of the client device 100 to the second encoded URL on the content server 300, the content server 300 will receive the second encoded URL. Hence, the content server 300 can extract and store the transaction ID from the second encoded URL. If the second encoded URL contains other information (e.g. authentication

information), this would also be extracted from the second encoded URL. In embodiments in which the second encoded URL contains authentication information, then this can be used by the content server 300 to authenticate the user. For example, the second encoded URL may contain information acting as a key, and without this key information present in the second encoded URL, the content server 300 may stop processing the second encoded URL. This can present unauthorised or unwanted access to URLs on the content server 300.

For example, the second encoded URL may contain information acting as a key, and without this key information present in the second encoded URL, the content server 300 may stop processing the second encoded URL. This can present unauthorised or unwanted access to URLs on the content server 300.

In embodiments in which the second encoded URL contains information about the user or the client device 100, this can enable the content server 300 to deliver personalised or device specific content to the client device 100. At step S20, the content server 300 stores tracking information indicating that the user accessed the predetermined web page. This can be done in a number of ways. For example, on receipt of the transaction ID, the content server 300 could query the tracking server 200 for information related to the user. In response to such a query, the tracking server 200 could provide information about the user to the content server 300.

For example, the tracking server 200 might store that MSISIDN is associated with a housewife aged 30-40, and could pass this information on to the content server 300, where it could be stored. In other words, the tracking server 200 could pass on rough category information or any associated data stored in the tracking server to the content server 300, and the content server 300 could then track how different categories of user's access their web pages from the SMS links sent to users.

In other embodiments, the transaction ID can act as a unique code for the user over a number of different transactions, enabling the content server 300 to build up a picture of the activity of the user by comparing different times the user with that transaction ID accessed content on the content server 300. Such a unique code for the user could be unique to the system of this embodiment, and thus there would fewer privacy concerns than using an ID such as the MSISDN that is publically identifiable.

Although the above has been described in relation to the client device 100 accessing the tracking server 200 via the mobile operator network 410, it will be appreciated that the same processes will occur if the client device 100 accesses the tracking server 200 via the WiFi access point 420. In other words, the tracking system of this embodiment is independent of the way in which the client device 100 is connected to the Internet. Thus it is not reliant on information (e.g. IP address) that is a characteristic of a particular Internet connection.

Furthermore, the system of this embodiment uses MSISIDNs to track user's access to a particular web page (as the MSISIDN is the user ID) without passing the MSISIDN over the network. Hence, this embodiment can track users using MSISIDNs, without needing to send this information.

By using this embodiment, the fact that the user accessed the predetermined web page can be tracked. This tracking method requires no prior knowledge about the user, except for the MSISIDN, Twitter handle or email address. In particular, tracking can be performed without any information being prestored on the client device (e.g. a cookie). Furthermore, embodiments such as this are particularly suited to sending links for tracking to client devices over mobile messaging systems (e.g. SMS) or other services in which message character lengths are limited. This is because of the URL shortening process used to produce the encoded URL.

In addition, it will be appreciated that the tracking server of the above embodiments may provide other functions. For example, it will be appreciated that the HTTP request received at step 5 of Figure 5 and step S16 in Figure 8 may contain a variety of information about the client device. For example, the HTTP request may contain information that can be used to indentify the client device (e.g. make and model number). This device information could be used by the tracking server (e.g. by looking up this data in an internal or external device registry) to determine the nature of the client device.

The tracking server could use this device identification information to redirect the client device to a device specific version of the predetermined web page. Alternatively, the tracking server could append this device identification information to the redirection URL (which could be a second encoded URL as discussed above), and the content server could use this information to provide the client device with device specific content.

Carrying out device detection at the tracking server 200 in this way is associated with a number of advantages. For one it enables content servers 300 to implement redirection to device specific pages without themselves having to carry out any device detection.

Furthermore, it even enables the tracking server 200 to redirect to different content servers 300 based on the device detection. For example, the Internet resource to which the redirection URL redirects may be a propriety app store. It will be appreciated that two different client devices may wish to access the same content (i.e. a link to a conversion of the same app) on different propriety app stores. In this example, based on the device detection at the tracking server 200, the tracking server 200 can redirect the client device 100 to the appropriate propriety app store. This is associated with a number of advantages. It enables tracking to be centrally performed over a number of content servers (who being competitors may not wish to share data), with no modifications required at the content servers. Figure 9 shows a system for tracking a user accessing a web page according to a third embodiment comprising a client device 100, a tracking server 250 and a web content server 300. Each of these is capable of communicating with each other over suitable networks, In this embodiment, the client device 100 is a mobile device, as shown in Figure 6 and will not be discussed in detail again.

Figure 10 schematic shows the tracking server 250 in more detail. The tracking server 250 comprises a storage unit 251, an encoder 253, a communications interface 255, a decoder 256, and a tracking datastore 257.

In this embodiment, the tracking server 250 is in communication with an external ID datastore 210, an external URL datastore 220, and an external message sender 230. In this embodiment, the client device 100 is capable of communicating with the tracking server 250 via the mobile operator network 410 or via a WiFi access point 420. It will of course, be appreciated that in practical embodiments, the client device 100 may be able to communicate with the tracking server 250 by other ways, but these two ways are shown for ease of description.

Hence, this embodiment differs from that shown in Figure 5 in that the tracking server 250 is in communication with an external message sender 230. The external message sender 230 is capable of sending SMS messages to the client device 100 via the mobile operator network 410.

The embodiment of this embodiment is similar to that shown in Figure 8. The main difference is that at step S15, it is not the tracking server 250 that sends the SMS message to the client device 100, but the external message sender 230. For example, the tracking server 250 could prepare the shortened URL (i.e. the encoded URL that uniquely relates to the user and to the web page at the content server 300) and then pass this information to the external message sender 230. An advantage of this process is that any customer specific, identity or segmentation information provided by a marketing expert to the tracking server in the cloud can be accessible by different content servers and messaging sending systems for

personalisation of the user's journey.

Figure n shows a tracking server 270 according to a fourth embodiment of the invention.

The tracking server 270 comprises a UI interface / Web interface 271, a Stats & Reports Generator 272, a URL Redirector and Meta Data Enhancer 273, a User profile Collector 274, a Service Registry 275, a Short URL Generator 276, a Device Detector 277, a Client API Interface 278, a User Profiles database 279, a Transaction logs database 280, a Client & Service Details Registry 281, a Device Registry 282, and a HTTP Handler 283. In this embodiment, the tracking server 270 is arranged to facilitate a SMS marketing campaign for a content owner, with the content owner associated with one or more content servers storing Internet resources. In this embodiment, the Internet resource is a web page. However, in other embodiments, the Internet recourse maybe any an online or on-device resource. For example, the Internet recourse may be content on a propriety app store.

The Short URL Generator 276 is able to take input from a content owner (manual or automated) in order to generate a shortened link to the tracking server that is responsible for tracking the user interaction and redirecting the user based on parameters supplied by the content owner.

The HTTP Handler 283 is arranged to receive the incoming HTTP Request to the shortened URL from the client device, and to extract the target URL and various device parameters from the HTTP Request. An appropriate action (such as redirection to the linked service URL with meta-data) is then performed. The HTTP Handler 283 forms the appropriate HTTP response and sends this back to the requesting device. In this embodiment, the HTTP Handler 283 is arranged to support HTTP protocol versions 1.0 and 1.1. In this embodiment, the headers tracked by the HTTP Handler 283 are shown in Table

1. Table 1

The Service Registry 275 stores the service URL and meta-data for each of the registered services and the corresponding user ID from the User Profile.

The Device Registry 282 has a library of mobile devices, and stores specific properties of each mobile device. It will be appreciated that each mobile device is associated with a large number (100+) of parameters, including:

Manufacturer

Model

Phone OS

Supported content types

· Screen resolution

Phone features - Bluetooth, WiFi, NFC, GPS etc.

Browser type. The User Profile database 279 stores user profile data including Unique ID, Device Make, Model, Services accessed, etc.

The Short URL Generator 276 is responsible for the generation and storage of the Short URL from the long URL that has been provided for a given service. The Short URLs used in this are randomly generated and publicly accessible.

In this embodiment, the Short URLs are generated using base 62, assuming 26 uppercase letters, 26 lowercase letters and 10 numbers (26 + 26 + 10), with the length of the short URL being 6 characters.

The URL Meta-data Enhancer 273 handles the concatenation of extra parameters required for the long URL of the HTTP request, if required, before providing the long URL for redirection. Appended data for the long URL specific to a particular user can added from the User Profile and is configurable. Typical parameters that are available for enhancing are listed below.

Appending of data can be policy driven. In cases where there are privacy/security concerns in passing data in a querystring, details can be queried via the SmartLink API using the transaction ID passed in the long URL. For example, the system may have a global setting that restricts the Unique Identifier (MSISDN, Twitter handle, etc.) from being appended to the URL. Therefore, in order to extract that unique ID a callback will need to be made to the system with a transaction ID in order to access this data. The Stats & Reports Generator 272 handles the generation of statistics for a service based on transactions and makes reports available as part of a web interface. Two types of reports are provided:

• Out of the box reports to monitor the service in real time

· Ad-hoc query interface which lets the end user create custom historical reports The reports are designed to track all interactions made by the end user, in addition to the lifecycle of a SmartLink. The reports can provide information as to how many times the user clicked the SmartLink, when they clicked it, from what device, OS and location, plus many others. They may also show what that SmartLink refers to in terms of how long URLs associated with it. As the validity of the link may be time bound (i.e. the

SmartLink is reserved for that particular long URL), this information will also be made available.

The Client API Interface 278 is responsible for all API access to the system. In this embodiment, the API is a RESTful JSON interface, though other embodiments could use other interfaces.

The UI Interface / Web Interface 272 is a secure, web-based interface that enables the creation of services in addition presenting report information for those services.

The operation of this embodiment will now be explained with the aid of Figure 12. In this embodiment, the client device has an SMS application that can receive SMS messages from a TELCO SMSC and display the SMS to the user along with an embedded short link.

At step S31, the client device receives an SMS with an embedded short link. The embedded short link is a shortened URL pointing to the tracking server 270, with the form: http://smrtlnk.com/Ax6dDf where "smrtlnk.com" is the domain of the tracking server 270 and "Ax6dDf ' is the code.

At step S32, the user clicks on the link in the SMS application of the client device.

The SMS application will then launch the default web browser of the client device and will send an HTTP request to the URL as per the link.

The HTTP request will contain some or all of the following parameters:

• The device browser name and its version.

· Operating System of the device (smartphone).

• Device Model. IP address of the Operator Gateway / ISP

Content types supported

Language of the browser The HTTP request is routed to the Operator GGSN or Internet Gateway. In the case of the HTTP request being routed the Operator GGSN, some of the parameters in the HTTP request may be removed or added based on policies of the Operator. For example, the MSISDN and IP address of the device are blocked at the Operator Gateway.

At step S33, the HTTP request is passed to tracking server 270 for processing.

The tracking server 270 resolves the corresponding service URL and will forward the request from the device to the service URL. The "service URL" is the long URL(s). So the tracking server looks at the SmartLink and derives the correct long URL from it.

The Service can then send back an appropriate response usually as an HTML/xHTML page that can contain content, information, navigation links that are specific to the attributes passed by the tracking server. Hence, the content server can translate the attributes supplied by the tracking server in the long URL to provide a personalised experience for the user. Then, a personalized page is served to the user - even without user information being passed by the Device/Telco. Hence, the system does not rely on the device or operator network providing the personally identifiable information or campaign specific parameters or attributes - they are passed in the long URL or can be queried using the transaction ID.

In more detail, at step S34, the tracking server 270 uses the code Ax6dDf to look up the MISISDN of the client device. At step S35, the Device Detector 277 uses Device Model information in the HTTP request to query the Device Registry 282 in order to detect the make and model of the client device.

At step S36, the tracking server 270 detects SmartLink code from the short URL.

At step S37, the tracking server 270 gets the get the long URL(s) based on the

SmartLink code. At step S38, the tracking server 270 gets the URL on the content server for redirection based on redirection type. In other words, depending on the results of the device detection, the tracking server 270 will select the appropriate redirection URL.

Furthermore, the selection of the appropriate redirection URL may depend on other parameters of the user to enable user appropriate content to be delivered.

At Step 39, the tracking server 270 redirects the client device to the URL on the content server, with a transaction ID appended to it. In other words, if the URL of the predetermined web page is http://www.contentserver.com, then the redirection URL that the client is redirected to could have the form:

where 3x5AAd is the transaction ID and 44123456789 is the user's MISISDN. In this embodiment, the transaction ID is information that is unique to the user's request to view the predetermined web page at this time.

It will, of course, also be appreciated that the redirection URL that the client is redirected may have other additional information appended to it. Furthermore, in some embodiments, information that could publically indentify the user (e.g. the user's MISISDN) is not appended.

Then, at Step 41, the tracking server 270 stores transaction details in the Transaction logs 280. In this embodiment, a record of the transaction ID, MISISDN and the page on the content server that the client device was redirected to is stored. In other

embodiments, other parameters such as time and date parameters may be stored for the chronological representation of events.

At Step 41, the client device navigates to the redirection URL. At steps S42, and S43, the content server fetches the transaction ID and MISISDN. Then at step S44, the content server responds to the client device with the requested content.

At step 45, the content server requests the transaction details from the tracking server 270 using the transaction ID, and at S46 a response is sent to the content server with the transaction details. In this embodiment, the transaction details are information relating to that particular user, including their unique id and any user-specific campaign parameters or attributes.

As discussed above, embodiments of the invention provide a tracking server for tracking a user accessing an Internet resource on a content server that comprises an encoder arranged to generate an encoded URL comprising information related to a user ID, with the encoded URL pointing to a tracking server. A mechanism is provided for sending the encoded URL to a client device of the user. The client device receives an indication from the user that the user wishes to visit the encoded URL, and sends a request to the tracking server. On receipt of the request from the client device, the tracking server is arranged to obtain the information related to the user ID of the user from encoded URL, and to redirect the web browser of the client device to a URL on the content server corresponding to the Internet resource. Embodiments of the invention also provide a system for tracking a user accessing a web page, comprising an ID datastore comprising a user ID relating to the user and a URL datastore comprising a URL corresponding to a predetermined resource on a content server. The system also comprises an encoder arranged to generate an encoded URL comprising information related to the user ID, the encoded URL pointing to a tracking server and a mechanism for sending the encoded URL to a client device of the user. The client device of the system comprises a web browser, and the client device is arranged to receive an indication from the user that the user wishes to visit the encoded URL. On receipt of such an indication, the web browser of the client device is arranged to send a request to the tracking server. Then, on receipt of the request from the client device, the tracking server is arranged to obtain the information related to the user ID of the user from encoded URL, and to redirect the web browser of the client device to a URL on the content server corresponding to the predetermined resource.

In some embodiments, the tracking server is arranged to store tracking data indicating that the user with that user ID would like to visit the predetermined resource. In other embodiments the storing of tracking information can take place on the content server.

Many further variations and modifications will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only, and which are not intended to limit the scope of the invention, that being determined by the appended claims.

Claims

Claims l. A system for tracking a user accessing a predetermined resource on a content server, comprising:

an ID datastore comprising a user ID relating to the user;

a URL datastore comprising a URL corresponding to a predetermined resource on a content server;

an encoder arranged to generate an encoded URL comprising information related to the user ID, the encoded URL pointing to a tracking server;

a mechanism for sending the encoded URL to a client device of the user;

wherein the client device comprises a browser, the client device being arranged to receive an indication from the user that the user wishes to visit the encoded URL, wherein on receipt of said indication the browser of the client device is arranged to send a request to the tracking server;

wherein on receipt of the request from the client device, the tracking server is arranged to obtain the information related to the user ID of the user from encoded URL, and to redirect the browser of the client device to a URL on the content server corresponding to the predetermined resource.

2. A system according to claim 1, wherein the tracking server is arranged to store tracking data indicating that the user with that user ID would like to visit the predetermined resource.

3. A system according to claim 1 or 2, wherein the encoded URL comprises an URL pointing to the tracking server with information relating to the user ID appended to it.

4. A system according to any one of claims 1 to 3, wherein the encoded URL is created by using an URL shortening process.

5. A system according to any one of claims 1 to 4, wherein the URL on the content server corresponding to the predetermined resource is a second encoded URL.

6. A system according to claim 5, wherein the second encoded URL is encoded with information relating to the user ID, optionally wherein the second encoded URL is encoded with a transaction ID, with the tracking server being arranged to store information relating the transaction ID to the user ID.

7. A system according to claim 5 or 6, wherein the second encoded URL comprises an URL pointing to the predetermined resource with the information relating to the user ID appended to it.

8. A system according any one of claims 1 to 7, wherein the content server is arranged to store tracking data indicating that the user accessing the second encoded URL would like to visit the predetermined resource.

9. A system according any one of claims 1 to 8, wherein the encoded URL is sent to the client device via SMS, MMS or other mobile message platform.

10. A system according any one of claims 1 to 9, wherein the user ID is any one or combination of a Twitter handle, user name, customer ID number, or MSISDN.

11. A system according any one of claims 1 to 10, wherein the tracking server is arranged to determine device information from the request from the client device, the device information indenting at least one property of the client device.

12. A system according to claim 11, wherein the tracking server is arranged to use the device information to determine which URL on the content server corresponding to the predetermined resource to redirect the client device to.

13. A system according to claim 11 or 12 when dependent on claim 4, wherein the second encoded URL comprises information relating to the device information.

14. A tracking server for tracking a user, comprising:

a mechanism for receiving a request from a browser of a client device that a user of the client device wishes to visit an encoded URL, the encoded URL relating to a predetermined resource and having been encoded with information related to a user ID of the user;

a mechanism for extracting the information related to the user ID of the user from encoded URL; and

a mechanism for redirecting the browser of the client device to a URL on a content server corresponding to the predetermined resource.

15. A tracking server according to claim 14, wherein the tracking server is arranged to store tracking data indicating that the user with that user ID would like to visit the predetermined resource.

16. A tracking server according to claim 14 or 15, wherein the encoded URL comprises an URL pointing to the tracking server with information relating to the user ID appended to it.

17. A tracking server according to any one of claims 14 to 16, wherein the encoded URL is created by using an URL shortening process.

18. A tracking server according to any one of claims 14 to 17, wherein the URL corresponding to the predetermined resource comprises a second encoded URL.

19. A tracking server according to claim 18, wherein the second encoded URL is encoded with a transaction ID, the transaction ID being useable by a content server of the predetermined resource to track the user.

20. A tracking server according to claim 18 or 19, wherein the second encoded URL is encoded with information relating to the user ID.

21. A tracking server according to any one of claims 18 to 20, wherein the second encoded URL comprises an URL pointing to the predetermined resource with information relating to the user ID appended to it.

22. A tracking server according to any one of claims 14 to 21, wherein the encoded URL is sent via SMS, MMS or other mobile message platform by the tracking server.

23. A tracking server according to any one of claims 14 to 22, wherein the user ID is any one or combination of a Twitter handle, user name, customer ID number, or MSISDN.

24. A tracking server according any one of claims 14 to 23, wherein the tracking server is arranged to determine device information from the request from the client device, the device information indenting at least one property of the client device.

25. A system according to claim 24, wherein the tracking server is arranged to use the device information to determine which URL on the content server corresponding to the predetermined resource to redirect the client device to.

26. A system according to claim 24 or 25 when dependent on claim 18, wherein the second encoded URL comprises information relating to the device information.

27. A tracking server according to any one of claims 14 to 26, wherein the tracking server is arranged to obtain the user ID relating to the user from an ID datastore, optionally wherein the ID datastore is external to the tracking server.

28. A tracking server according to any one of claims 14 to 27, wherein the tracking server is arranged to obtain the URL corresponding to a predetermined resource from a URL datastore, optionally wherein the URL datastore is external to the tracking server.