Click stream analysis

[0001] This invention relates to Web servers, and more particularly, to click stream analysis of client interactions with Web servers.

[0002] The increasing diversity of click stream analysis involves the analysis of user requests when visiting a Web site. Each request by a user represents a request to a server of the Web site that was made by the user ‘clicking’ on a visual object on a Web page on the Web site with a mouse or other input device. The visual object can be an icon, a hyperlink, or another logical representation of the request. These requests are stored in a Web server log for the Web site, where each log record typically corresponds to a single request for a single event. Click stream analysis is intended to aid Web site owners in understanding how visitors are using their Web site.

[0003] Current click stream analysis products typically provide aggregate path analysis reports, which show general trends of how users are using particular Web sites. The size of data that is accumulated for at a particular Web site can be enormous because the accumulated data includes each request by each user during each visit. If the Web site is actively used by the public, and multiple servers are used to provide web services to the Web site, the accumulated data can exceed one (1) terabyte in a period of 24 hours. For this reason, current click stream analysis products typically provide aggregate path analysis reports (e.g. path calculation reports) that are limited to a depth of six (6) user clicks or less from where a user enters the Web site. This limitation on click depth in aggregate path analysis reports has an inherent lack in granularity. In many instances, this lack in granularity for high user volume Web site causes a failure of the aggregate path analysis reports to adequately assist the Web site owner or analyst in reconstructing precisely what behavior (e.g. all of the series of ‘clicks’ or server-requests) led users to particular requests (e.g. purchasing an item) when visiting the Web site. For instance, the owner of a high user volume Web site, or an analyst thereof, desires to reconstruct each user request and represent the same in a path calculation report. To do so, the path calculation report will have to show more than six sequential clicks by the users. For this kind of exhaustive click stream analysis, the entire Web server log needs to be scanned, collated and queried, which requires excessive accumulation of data in an inefficient and time consuming process that is rarely justified by its expense.

[0004] A path calculation report is produced from data in a data structure that is derived from a Web log. The Web log contains each request, represented as a Universal Resource Identifier (URI), by each user of a Web site. The path calculation report can include a count of the users having the same click path through the Web site as well as the sequential order all of the URIs for each user request for each click path. Each URI for the path calculation report are derived from a decompression of a compressed fixed length number that represents the URI and that is stored in the data structure. The data structure also includes request entries in a request table representing each request by a user, visit entries in a visit table representing each visit by each user to the Web site, and summary entries in a summary table representing each unique click path followed by a user through the Web site.

[0011] Overview

[0012] To overcome problems including those described in the Background section, the following description introduces the broad concept of using a Web log to reconstruct each request made by a user to a server for a Web site during the user's visit to the Web site. The request is represented by a Universal Resource Identifier (URI). A visit is determined for a collection of requests made by the same user. The reconstruction logically represents all of the requests made by one user in one visit by compressing the corresponding one or more URI thereof to produce a fixed length number. The fixed length number is substantially unique for the sequence of clicks made by the user during the visit. This compression to a substantially unique fixed length number advantageously reduces data storage requirements. Due to the low data storage requirements made possible by compression techniques, the reconstruction scales to high user volume web sites. This reconstruction can then be used to prepare a path calculation report to show a relatively large number of clicks by each user, in the respective sequential order thereof, during a visit to a web site. The reconstruction, and/or the path calculation report, can be used to perform extensive behavior analysis across the click activities of many users in an aggregate form during their respective visits to the Web site.

[0013] An analyst may wish to examine the behavior of certain users that requested a “commerce event”. In particular, the analyst can use the reconstruction, and/or the path calculation report, to examine the sequence of all user clicks, across all users, that occurred prior to and/or subsequent to the commerce event. By way of example, and not by way of limitation, a commerce event can be any request made by a user at a Web site that is deemed a point of great interest, because the event typically represents a culmination of a user's navigational journey(s) through the Web site or the event results in some type of request that determines the outcome of the navigation. For instance, while visiting a Web site a user may purchase a product, click on an advertisement, add an item to a virtual shopping basket: all of which are the type of requests that might warrant a logging of a commerce event, because they represent special or the more interesting requests of a user's click activity.

[0014] Personnel managing the Web site can use the reconstruction, and/or the path calculation report, in a variety of ways, such as where additional or alternative requests can be considered to be a commerce event on their respective Web site. Thus, a commerce event may also be a designated event (i.e., a request) that marks a point in a user's click activity in which there is a desire to track and determine what the user's click activity was prior to and subsequent to such a designated request. By way of example, a software provider may want to designate a request to download free software as such a point, and then perform a click stream analysis with respect to an unlimited number of clicks prior to or after that point. To do so, one or more techniques including a hashing algorithm as described herein can be used to prepare an exhaustive path calculation report. This path calculation report is then used to perform a click stream analysis. Once the click stream analysis has been performed upon the exhaustive path calculation report with respect to the point of particular interest, the analyst may then have gained the best practical understanding of user behavior at the various Web pages of the Web site. Once such understanding might be with respect to a particular advertisement that had been shown to Web site users in a daughter window or in a banner. The click stream analysis can provide an understanding of the ‘reach and frequency’ of user exposure to the advertisement. The analyst can then use this understanding to suggest additions, deletions, and/or modifications to the Web pages of the Web site and thereby influence future behavior of prospective Web site users.

[0015] Exemplary Network Environment

[0016] FIG. 1 shows a network environment 100 in which a click stream analysis application 130 may be implemented. The network environment 100 includes representative Web services 102(1), . . . , 102(J), which provide services that can be accessed over a network 104 (e.g., Internet). The Web services, referenced generally as number 102, are programmable application components that are reusable and interact programmatically over the network 104, typically through industry standard Web protocols, such as Extensible markup language (XML), hypertext transport protocol (HTTP), and simple mail transfer protocol (SMTP), although other means of interacting with the Web services over the network may also be used, such as simple object access protocol (SOAP), remote procedure call (RPC) or object broker type technology.

[0017] Web services 102 are accessible directly by other services (represented by communication link 106) or a software application, such as Web service application 110 (as represented by communication links 112 and 114). Each Web service 102 is illustrated as including one or more servers that execute software to handle requests for particular services. Such services often maintain databases 107 that store information to be served back to requesters. Web services may be configured to perform any one of a variety of different services. Examples of Web services include login verification, notification, database storage, stock quoting, location directories, mapping, entertainment, shopping, calendars, news, games, ticketing, and so on. The Web services can be combined with each other and with other applications to build intelligent interactive experiences.

[0018] The network environment 100 also includes representative client devices 120(1), 120(2), 120(3), 120(4), . . . , 120(M) that utilize the Web services 102 (as represented by communication link 122) and/or the Web application 110 (as represented by communication links 124, 126, and 128). The client devices represented generally as number 120 may communicate with one another using standard protocols as well, as represented by an exemplary XML link 131 between clients 120(3) and 120(4).

[0019] The client devices 120 can be implemented many different ways. Examples of possible implementations include, without limitation, portable computers, stationary computers, tablet PCs, televisions/set-top boxes, wireless communication devices, personal digital assistants, gaming consoles, printers, photocopiers, and other smart devices.

[0020] The Web application 110 is an application designed to run on some type of network platform such as one or more server(s) 134. The Web application 110 may utilize Web services 102 when handling and servicing requests from client 120. The Web application 110 is composed of one or more software applications 130 that are executing on one or more servers 134 or other computer systems. Note that a portion of Web application 110 may reside on one or more of clients 120. Alternatively, Web application 110 may coordinate with other software on clients to accomplish tasks. In one exemplary implementation, one of the software applications 130 may include a Commerce Server™ family of products provided by Microsoft Corporation of Redmond, Wash., USA, and/or other application server application programs.

[0021] Web application 110 may include the ability to monitor Web services, servers, and/or client devices 120 interactions with one or more Web site(s) 160(1), . . . , 160(J). The Web sites, referred to generally as 160, can operate on Web services 102, servers 134 and/or client devices 120. Web application 110 may also be implemented at a client to monitor Web sites 160. Client 120(3) represents the situation where a Web application 110 including applications 162 (which may be identical to server-based applications 130), but modified for any number of client purposes to monitor interactions with Web sites 160.

[0022] Click Stream Analysis: Requests at Web Pages, Path Calculation Report

[0023] FIGS. 2-3 shows a Web site 160 operating on a server 201 and Web log 206 having records 304, 314 therein. Server 201 represents any type of computer device (such as the servers described with reference to FIG. 1) capable of performing functionality associated with hosting a Web site. Web site 160 comprises a set of pages. The pages are linked together allowing a visitor to move from one page another. The arrangement of pages constitutes a part of a Web site's content topology. A page or a set of pages can contain or point to a variety of resources, including images, text, scripts, links to resources and so forth. A user may make “requests” while on a page of the Web site by “clicking” on a designated location and being linked to a desired location or cause an event to occur. For example, a request may include clicking on and/or interacting with an advertisement, traversing from one page to another, purchasing an item, adding an item to a virtual shopping basket, etc.

[0024] Some of the requests made by a user may also be designated a commerce event by one of the software applications 130. As described above, a commerce event describes any request made by a visitor to a Web site that is deemed a point of great interest, because the event typically represents a culmination of a user's navigational journey(s) through a Web site or results in some type of request that determines the outcome of the navigation. For instance, while visiting a Web site a user may purchase a product, click on an advertisement, add an item to a virtual shopping basket: all of which are the type requests that are usually considered a commerce event, because they represent special or the more interesting requests of a user's click activity. Further, the software applications 130 may also contain the flexibility to permit personnel managing the Web site 160 to designate additional or alternative requests that they consider to be a commerce event on the Web site 160.

[0025] Each time a user makes a request on the Web site 160, the request invokes one or more applications 130 to log a Universal Resource Identifier (URI) corresponding to whatever resource, page, advertisement, or other related item was clicked-on as part of a record 304. Each record 304 is stored in Web log 206. Each record 304 may also contain information such as the type of request as designed by a Universal Resource Identifier (URI) 312, a user key 316 logically representing a user who paid a visit to the Web site 160, historical data (not shown), the date and time of the visit 318, how the user entered the Web site (not shown), what browser (not shown) was used to enter the site, a previous URI (not shown) of a different Web site that the user viewed that may have enabled the user to visit the present Web site, and other information pertinent to tracking a user's interactions with the Web site 160. Additionally, certain URI 312 maybe be of particular interest and the corresponding request can be designated as a commerce event record 314 in records 304 of Web log 206.

[0026] As used herein, a “visit” refers to a single sequence of requests made by a user, such as pages viewed while at a Web site from a certain period of time when the user enters the Web site, to when the user exits the Web site, where the time period between each chronologically contiguous click within the visit does not exceed a given timeout threshold. Click stream analysis application 202, through the log import module 260, is able to infer a visit from the web site 160 when no hits are received from a particular user after the last previous hit for a default period of time such as 30 minutes. In one implementation it is possible for the period of time used to determine what length of time should be used between the time a user enters a Web site to the time the user exits the Web site, to be determined by personnel managing the Web site. Click stream analysis application 202 permits this time to be selectable. Additionally, a visit may be determined by other techniques as described above. Of course, other durations, shorter or longer, may be selected for purposes of determining a visit. Other methodologies can also be used to infer a visit. For example, if the referring Universal Resource Locator (URL) is from a different domain than the site under analysis, then a visit can be inferred when the URL chain is broken.

[0027] In the example of FIG. 3, web log 206 shows the first six of many requests made by a single user (User1) of client device XYZ during one visit to web site 160. As per the first record 304, the User1 entered the Web site on Jan. 1, 2002 at 1 PM. User1 then added an item to a virtual shopping basket on the user's second click, as denoted by the URI 312 in record 314 of Web log 206. As such, the record 314 contains a request representing a commerce event. User1 then performed the next four requests as designated by URI 312 referencing, respectively, \path3, \path4, \path5, and \path6. Although web log 206 is shown in FIG. 3 as being truncated, it is intended to represent an unlimited number of requests (URI 312) of User1 as were made to the server(s) of the Web site 160 during the visit of User1. Of course, the web log 206 also contains each of the requests of all other users that visited the web site 160. Such requests, and users making the same, have been omitted from web log 206 depicted in FIG. 3 for the sake of brevity.

[0028] As shown in FIG. 2, click stream analysis application 202 (which may be part of the applications 130 of operate in conjunction with applications 130) is able to analyze a user's requests when visiting the web site 160. Click stream analysis application 202 includes a log import module 260 that imports (i.e., extracts) data from the web log 206. Optionally, the log import module 260 can import or extract data from the web log 206 of each of more than one server the services request from the users of the web site 160. Once these data have been imported and/or extracted, the click stream analysis application 202 then can parse these data and store the result thereof in a database 210. In one implementation, a SQL Server 2000™ product provided by the Microsoft Corporation of Redmond, Wash., USA is used to create and maintain the database 210, although other implementations are not limited to this particular arrangement. Click stream analysis application 202 also includes a reporting module 262 that analyzes information stored in the database 210, and based on that analysis, produces a path calculation report 208 that shows a number of sequential requests made by each user during their respective visits to the web site 160.

[0029] Database: Logical Representation of Tables from Techniques Including Hashing

[0030] The path calculation report 208 provides analysis concerning the Web log 206 and may be may produced by reporting module 262 by reconstructing visits to the Web site by one or more users. Each request performed by each user of the web site 160 is identified in the path calculation report 208, including a number of requests made by each user. This reporting includes any such request representing any record 314 in web log 206 that characterizes the purchasing of an item or other request of particular interest. The particular requests made by users prior to and/or subsequent to the requests of particular interest can be further examined in a Web analyst's review of the path calculation report 208. Thus, the path calculation report 208 permits personnel (e.g., analyst) to monitor the Web site 160 and to gather detailed information on all of any given user's click activity prior to and subsequent to any record 314 in web log 206 that logically represents a commerce event. The path calculation report 208 may be displayed to an analyst in soft form, such as by a display on a client device, or in other formats such as a hard copy printed by a printer.

[0031] The path calculation report 208 is produced by extracting data from the Web log 206 (performed by log import module 260), populating database 210 with information (also performed by log import module 260), and by searching database 210 for user click activity (performed by report module 262) according to default parameters or those requested by a Web site analyst. The database 210 can be organized in a fashion to permit the reconstruction of all of the user's visit from potentially several different servers. Consequently, by focusing-in on requests (those designated a “commerce event”) that were performed on the Web site that are of greater importance to the Web site analyst, it can be determined the precise behavior (unlimited series of requests on which pages) that led a user to make a request corresponding to the commerce event or what type of requests occurred after the commerce event.

[0032] Hashing Process 207

[0033] In one implementation, database 210 seen in FIG. 3 includes three tables: a request table 332, a visit table 334, and a summary table 336. Each table is described below. These tables need not be actually formed but can be kept as logical representations in database 210. Tables 332, 334, and 336 are formed by techniques that include compressing the corresponding one or more URI 312 of user/client 316 during one visit to produce a fixed length number. This fixed length number, for the purpose of click stream analysis, is sufficiently to uniquely represent any particular click path. In various implementations, the fixed length number can be formed by a hashing process 207. Due to the potentially immense amount of data needed to represent all user requests during a period of time at a high user volume web site, hashing process 207 can be used to represent the user activity with less accumulated volume of data than otherwise.

[0034] Hashing process 207 can be implemented by hashing the large string of arbitrary length represented by each URI 312 in a compression that produces a fixed length (e.g. 128-bits or 8 bytes) integer. The compression can be performed using known hashing algorithms. In one implementation, the CryptoAPI (Crypto Application Programming Interface) can be used as the hashing algorithm. In another implementation, the MD4 CryptoAPI hash algorithm can be used to create a 128-bit hash value for use by 32-bit computers. Other hashing algorithms include the CryptoAPI MD2, MD5, and Secure Hash Algorithm (SHA).

[0035] FIG. 3 shows a logical representation of the results of hashing process 207 for all clicks made by one user during one visit to the web site under analysis. An unlimited number of the user's click activity is represented by path item numbers 311 from one (1) to N as shown in the column titled “Path Item No.” in hashing process 207 in FIG. 3. Each path item number 311 is seen as a row in a table in the logical representation of hashing process 207. Each row includes URI 312 of the request by the user 316, a URI hash 328 which is the URI 312 after being hashed, a cumulative hash 324 which is a hash of the previous hashes, and a site depth 330 that represents the depth to which the user 316 clicked within the web pages of the Web site 160. The cumulative hash 324 for the row is formed by hashing the URI hash 328 of the row with each of the cumulative hashes 324 in the previous rows. In effect, the cumulative hash 324 uses the hash from the previous cumulative hash. As such, memory is not needed for all of the hashes of all the paths prior to the current path that is being processed. The table for hashing process 207 shows each hash by the delimiter “0x” and a sequential number. This representation is intended to be a fixed length number for URI hash 328 and for cumulative hash 324. URI hash 328 is a hash of URI 312. Cumulative hash 324 represents the entire click path of the user. As such, cumulative hash 324 will be substantially similar to like click paths of other users during other visits to web site 160.

[0036] Request Table 332

[0037] FIG. 3 shows a request table 332 in database 210 as having fields that make up one entry in the request table 332. The entry in request table 332 provide a logical representation of one request by a one user to a server for the web site during one visit by the user to the web site. The fields in the entry in the request table 332 are derived from one (1) row in the table depicted for the hashing process 207, with the exception of a previous cumulative hash 326 field which is the cumulative hash 324 of the immediately previous row and represents the last request made by the user to the server during the user's same visit.

[0038] Visit Table 334

[0039] FIG. 3 shows a visit table 334 in database 210 as having fields in one (1) entry that summarize the entries in the request table 332 for one user during one visit to the web site. Thus, the one (1) entry in visit table 334 provides a logical representation of one visit by one user to the web site. The fields in the entry in the visit table 334 are derived from the rows in the request table 332 corresponding to the Web site visit by the user. The fields 324 and 330 in visit table 334 corresponds to the last entry for the user's visit in the request table 332. A user key field 316 in visit table 334 is taken from web log 206 and is a logical representation of the user at the web site. A visit duration field 340 is derived from the first and last date/time fields 318 in the web log 206 for the respective entry and exit of the user at the web site to quantify the length of the user's visit. Alternatively, a value for the visit duration field 340 can be inferred such as where the time from when the user enters the web site exceeds a given threshold (e.g. a timeout threshold). The duration of the user's visit can thus be inferred when no hits are received from the particular user after the last previous hit for a default period of time, such as 30 minutes. Of course, other durations, shorter or longer, may be selected for purposes of determining a visit. Other methodologies can also be used to infer the visit and a duration thereof. For example, if the referring URL is from a different domain than the web site under analysis, then a visit by a user can be inferred when the URL chain is broken and a corresponding length thereof can be calculated.

[0040] Summary Table 336

[0041] An optional summary table 336 can be formed by identifying each unique cumulative hash 324 that is formed in the hashing process 207 across all visits by all users during a period time. Cumulative hash 324 in optional summary table 336 uniquely represents only one particular click path through the web site that was taken by a user during a visit. Each such unique click path is assigned to a unique count 338. Count 338 can be made unique, for example, by an assigned ordinal that advances by one for each unique click path detected at the web site.

[0042] Web Log Processing, Hashing, and Path Calculation Reporting

[0043] FIG. 4 is a flow chart illustrating an exemplary method 400 for processing Web log 206 to reconstruct all requests made by a user during the user's visit to a Web site. Method 400 includes blocks 402-414. The order in which the method is described is not intended to be construed as a limitation. Additionally, portions of the operations may be optional or performed intermittently. Furthermore, the method 400 can be implemented in any suitable hardware, software, firmware, or combination thereof. In the exemplary implementation, method 400 is executed by click stream analysis application 202 in conjunction with software applications 130.

[0044] Web log 206 is processed at block 402 to identify each visit, and the duration 340 thereof, by a user 316, and to identify each URI 312 within the visit by the user 316. At block 404, the hashing routine 207 is performed for each URI 312 within each visit by the user 316. As such, the hashing routine 207 forms the URI hash 328, and forms the cumulative hash 324 by hashing the present URI hash 328 with each previous cumulative hash 324 that had been formed for the user's visit. A site depth 330 is set for each request by the user 316 during the visit to the web site, as represent by the path item no. 311 in the hashing process 207. Note that while the path item no. 311 is an assigned ordinal that advances by one for each request by the user during the visit, up to a value of ‘N’, the site depth 330 is not so assigned but is rather a logical representation of the depth to which the user 316 clicked within the web pages of the web site.

[0045] At block 406, an entry is formed in request table 332 for each request (path item no. 311) by one user 316 during a visit to the web site. At block 408, an entry is formed in visit table 334 for one visit by one user 316 to the web site. At block 410, an entry can be formed in the optional summary table 336 by assigning a unique count 338 to each unique cumulative hash 324 formed in hashing process 207. At block 412, one or more of the tables 332, 334, and optionally 336 can be stored in database 210. As stated above, tables 332, 334, and 336 need not be actually formed but can be deduced by equivalent logical representations from data in web log 206. A path calculation report can be produced at block 414 of method 400.

[0046] The path calculation report is derived from data in one or more of the tables 332, 334, and optionally 336 stored in database 210. As such, the path calculation report can contain any of variety of different representation of the data stored in database 210 that an analyst of the Web site 160 might find helpful. For instance, the analyst may wish to identify each unique click path that has been taken by one or more users through the Web site, as well as the number of users that took each unique click path. The sequence requests of the unique click path can be deduced as to the respective URI 312 from respective entries in the request table 332 and the visit table 334, with or without use of the optional summary table 336. These sequences of URI 312 can be shown in the path calculation report path and then used to perform extensive behavior analysis across the click activities of many users during their respective visits to the Web site.

[0047] By way of example, and not by way of limitation, there is set forth as follows an exemplary report layout that could be used to produce a Path Calculation Report that is derived from the data in tables 332, 334, and 336 of database 210:

[0048]

Path Calculation Report
Time Period 01/01/2003: 6:00 AM-10:00 PM (EST)
Web Site: “www. OnLineRetailer.com”
Number of User's Visiting the Web Site: 9999
Number of Visits To The Web Site: 9999
Users	URI 1	URI 2	URI *	URI **		URI ***	URI N
999	\path1\default.asp
999	\path1\default.asp	\path2
* * *	* * *	* * *	* * *	* * *	* * *	* * *
999	\path3\search	\path3\sea.results
* * *	* * *	* * *	* * *	* * *	* * *	* * *
999	\path4\product.default.asp?CEVT={T=BSK,EVT=Add,PRID=X}
		\path5	\path6	\path7		* * *	\path22
* * *	* * *	* * *	* * *	* * *	* * *	* * *
999	\path5\store\buyit\	\path1\default.asp
			\path9	* * *	* * *	* * *	\pathK

[0049] The foregoing exemplary Path Calculation Report has a heading for a particularized date and time period that includes the number of visits to and users of a designed Web site to which the report pertains. Each row of the Path Calculation Report shows, in sequential order, the unique click path through the designed Web site that was taken by the number users shown in the “Users” column. As such, the “Users” column shows, for each row, the number of users that followed the particular click path of that row. Each subsequent column in that row shows, in sequential order, each of the one or more URI 312 corresponding to each of the requests of in the unique click path of the row on the report. As shown on the report, an unlimited number (‘N’) of requests can be shown for each row on the Path Calculation Report. An unlimited site depth (‘K’ for ‘\pathK’) for the clicks of a user into the web pages at the Web site can also be shown. A discussion of the derivation of the data for the Path Calculation Report from database 210 and web log 206 follows.

[0050] The web log 206 has therein a plurality of URI each corresponding to a request made by a user 316 to a server of a Web site 160. The Web site 160 contains one or more web pages. Each user 316 of the Web site 160 and each visit made by each user 316 of the Web site 160 can be identified from the web log 206. A site depth 330 in the web pages of the web site 160 corresponding to each URI 312 can also be identified. The site depth 330 is the sequential number of the request by the user 316 in the visit (e.g. 1^st request, 2^nd request, 3^rd request, etc.). Consequently, the last request that is made by a user during a visit to a Web site will have the highest value site depth 330. Each URI 312 can be compressed, as discussed above, to form a URI hash number 328 that has a first fixed length.

[0051] Within each identified visit by each identified user 316, and for each URI 312 within the visit, a request entry can be made in the request table 332. The request entry in the request table 332 can include the site depth 330 of the corresponding request, the URI hash number 328, and a previous cumulative hash number 326 of a second fixed length. The previous cumulative hash number 326 can be is formed by compressing together each of the URI hash numbers 328 of the chronologically prior request entries of the visit that are in the request table 332. This compression can be a logical operation rather than an operation that is physically performed. Even though all the previous requests are available in a database, there is no need to literally go and retrieve all of the computed hashes for the previous requests and then to recalculate the cumulative hash. Rather, the hash can be calculated based on the cumulative hash (e.g. only one number) plus the new incoming URI (e.g. the string). In practice, if is likely that the combination of the single number that is hashed with the new incoming path (e.g. the URI) will yield a new unique number (e.g. the new cumulative hash). By knowing the depth, another degree of uniqueness is added.

[0052] The request entry also includes a cumulative hash number 324 of a third fixed length that is formed by compressing the URI hash number 324 with the previous cumulative hash number 326. These compressions can be performed as was discussed above with respect to compression algorithms.

[0053] A visit entry can be formed in the visit table 334 for each visit by a user 316 to the web site 160. The visit entry can include a visit duration 330 of the visit by the user 316 that can be derived from the date/time 318 of the requests made during the visit, or by other techniques disclosed herein. The visit entry can also include a logical representation 316 of the user and, for the chronologically last request entry within the visit, the cumulative hash number 324 and the site depth 330 of the corresponding request.

[0054] A summary entry can be formed in the summary table 336 for each unique cumulative hash number 324 in the visit entries of visit table 334, where each summary entry includes a count 338 that represents the number of visit entries in visit table 334 that have the same cumulative hash number 324.

[0055] The sequential order of all of the URI that correspond to each summary entry in the summary table 336 can be derived by performing a lookup in a table that can be formed so as to correspond to each of the URI hash numbers 324. In order to obtain a path calculation report by using the tables described above, a query is first made to the summary table 336. This first query will give a cumulative hash for a given path that can be used in a second query made against the request table 336. This second query gives an individual URI hash. The individual URI hash can be used in a third query of an additional ‘URI table’ which maps a URI hash to a string. In addition, the URI table gives a “pointer” to the previous cumulative hash. Given the foregoing, a process can be repeatedly performed. In this process, a query is made to the request table 336 based on the cumulative hash, and then the individual URI hash and the previous path can then be found as described above.

[0056] As an alternative, the sequential order of all of the URI that correspond to each summary entry in the summary table 336 can be derived by decompressing each URI hash number 324 in each request entry of request table 332 that corresponds to one visit entry in visit table 334 that in turn corresponds to each summary entry in summary table 336. This derivation can be performed by identifying one visit entry in the visit table 334 that corresponds to one of the summary entries in summary table 336 according to a match of the cumulative hash number 334 in each. Then, an identification can be made of each request entry in request table 332 that corresponds to the identified one visit entry in visit table 334 by matching in each the cumulative hash number 324 and the site depth 330.

[0057] Thereafter, an identification can be made of each request entry in request table 332 that corresponds to the identified one request entry in request table 332 within the one visit by the one user 316. When so identified, a decompression can be performed of each URI hash number 328. The decompression of the URI hash number 328 yields the URI of the request. This decompression will preferably be conducted in the sequential order specified by the value of site depth 330 so that the ‘path click’ of the visit will be reconstructed in proper order. As such, the URI of each request in each entry in request table 332 will be identified for each unique visit to the Web site 160.

[0058] The identification of each of the request entries in request table 332 that correspond to the identified one request entry within the one visit by the one user 316 can be performed by identifying each match of the previous cumulative hash number 326 of the one request entry with the cumulative hash entry 324 of another said request entry that has a site depth 330 that is less than the site depth 330 of the one request entry. The first, second and third fixed lengths as used in the compression algorithms (e.g. CryptoAPI, MD2, MD5, SHA, etc.) can have the same length.

[0059] Exemplary Computing System and Environment

[0060] FIG. 5 illustrates an example of a computing environment 500 within which the applications 130 including click stream analysis application 202 described herein can be either fully or partially implemented. Exemplary computing environment 500 is only one example of a computing system and is not intended to suggest any limitation as to the scope of use or functionality of the network architectures. Neither should the computing environment 500 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary computing environment 500.

[0061] The computer and network architectures can be implemented with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, gaming consoles, distributed computing environments that include any of the above systems or devices, and the like.

[0062] The applications 130 (including click stream analysis application 202) may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The applications 130 (including click stream analysis application 202) may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

[0063] The computing environment 500 includes a general-purpose computing system in the form of a computer 502. The components of computer 502 can include, but are not limited to, one or more processors or processing units 504, a system memory 506, and a system bus 508 that couples various system components including the processor 504 to the system memory 506.

[0064] The system bus 508 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.

[0065] Computer system 502 typically includes a variety of computer readable storage media. Such media can be any available media that is accessible by computer 502 and includes both volatile and non-volatile media, removable and non-removable media. The system memory 506 includes computer readable storage media in the form of volatile memory, such as random access memory (RAM) 510, and/or non-volatile memory, such as read only memory (ROM) 512. A basic input/output system (BIOS) 514, containing the basic routines that help to transfer information between elements within computer 502, such as during start-up, is stored in ROM 512. RAM 510 typically contains data and/or program modules that are immediately accessible to and/or presently operated on by the processing unit 504.

[0066] Computer 502 can also include other removable/non-removable, volatile/non-volatile computer storage media. By way of example, FIG. 5 illustrates a hard disk drive 516 for reading from and writing to a non-removable, non-volatile magnetic media (not shown), a magnetic disk drive 518 for reading from and writing to a removable, non-volatile magnetic disk 520 (e.g., a “floppy disk”), and an optical disk drive 522 for reading from and/or writing to a removable, non-volatile optical disk 524 such as a CD-ROM, DVD-ROM, or other optical media. The hard disk drive 516, magnetic disk drive 518, and optical disk drive 522 are each connected to the system bus 508 by one or more data media interfaces 526. Alternatively, the hard disk drive 516, magnetic disk drive 518, and optical disk drive 522 can be connected to the system bus 508 by a SCSI interface (not shown).

[0067] The disk drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for computer 502. Although the example illustrates a hard disk 516, a removable magnetic disk 520, and a removable optical disk 524, it is to be appreciated that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like, can also be utilized to implement the exemplary computing system and environment.

[0068] Any number of program modules can be stored on the hard disk 516, magnetic disk 520, optical disk 524, ROM 512, and/or RAM 510, including by way of example, an operating system 526, one or more application programs 528, other program modules 530, and program data 532. Each of such operating system 526, one or more application programs 528, other program modules 530, and program data 532 (or some combination thereof) may include an embodiment of the applications 130 (including click stream analysis application 202).

[0069] Computer system 502 can include a variety of computer media indentified as communication media. Communication media typically embodies computer readable instructions, data structures, program modules, and includes any information delivery media.

[0070] A user can enter commands and information into computer system 502 via input devices such as a keyboard 534 and a pointing device 536 (e.g., a “mouse”). Other input devices 538 (not shown specifically) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and/or the like. These and other input devices are connected to the processing unit 504 via input/output interfaces 540 that are coupled to the system bus 508, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).

[0071] A monitor 542 or other type of display device can also be connected to the system bus 508 via an interface, such as a video adapter 544. In addition to the monitor 542, other output peripheral devices can include components such as speakers (not shown) and a printer 546 which can be connected to computer 502 via the input/output interfaces 540.

[0072] Computer 502 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computing device 548. By way of example, the remote computing device 548 can be a personal computer, portable computer, a server, a router, a network computer, a peer device or other common network node, and the like. The remote computing device 548 is illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer system 502.

[0073] Logical connections between computer 502 and the remote computer 548 are depicted as a local area network (LAN) 550 and a general wide area network (WAN) 552. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When implemented in a LAN networking environment, the computer 502 is connected to a local network 550 via a network interface or adapter 554. When implemented in a WAN networking environment, the computer 502 typically includes a modem 556 or other means for establishing communications over the wide network 552. The modem 556, which can be internal or external to computer 502, can be connected to the system bus 508 via the input/output interfaces 540 or other appropriate mechanisms. It is to be appreciated that the illustrated network connections are exemplary and that other means of establishing communication link(s) between the computers 502 and 548 can be employed.

[0074] In a networked environment, such as that illustrated with computing environment 500, program modules depicted relative to the computer 502, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs 558 reside on a memory device of remote computer 548. For purposes of illustration, application programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer system 502, and are executed by the data processor(s) of the computer.

[0075] Conclusion

[0076] The entire click path of a user during a visit to a web site can be reconstructed by using click path compression techniques. A path calculation report can be produced from the reconstruction to show the sequential order of a virtually unlimited number of clicks in each unique click path during any web site visit by any user. The reconstruction, and/or the path calculation report, can be used to perform extensive behavior analysis of the web site users.

[0077] Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.