System for reconfiguring a web site or web page based on real-time analytics data
Machine-implemented methods for reconfiguring a web site configuration are provided. In one aspect, a method includes acquiring low latency web site traffic data for a web site, and automatically modifying a layout or content of the web site or a web page on the web site based on information derived from the acquired low latency web site traffic data for the web site. Systems, graphical user interfaces, and machine-readable media are also provided.
Latest Google Patents:
Web site analytics involves the analysis and reporting of web site traffic data to an associated publisher. A publisher is an entity that owns and/or manages a particular web site. The publisher can monitor web site analytics data related to user visits and links to the web site by using web site analytics tools provided by third parties.
Existing web site analytics data systems work well for processing a high volume of web traffic data in order to provide interactive reports over substantial periods of time with high fidelity. However, these systems incur a high level of latency from hit occurrence to hit reporting, and also do not allow reports to segment in a fine and granular time basis. Consequently, existing web site analytics data systems have difficulty in monitoring sudden spikes or drops in traffic, or for tracking, for example, a propagation of a link to the publisher's web site over a social networking site, which can typically unfold in a time period of minutes.
Furthermore, the high latency of web site analytics reporting makes it more difficult for publishers to implement web site analytics on their web sites. Because it takes a longer period of time to report analytics data for a web site to publishers, publishers are unable to view web traffic data for their web site in a timely manner. Furthermore, because it takes a longer period of time for reports to show up, publishers also often fail to timely reconfigure their web page or web site in response to recently occurring changes in web traffic, let alone notice the changes or an erroneous deployment of web site analytics tracking code on associated web sites.
SUMMARYAccording to one aspect of the disclosure, a machine-implemented method for reconfiguring a web site is described. The method includes acquiring low latency web site traffic data for a web site, and automatically modifying a layout or content of the web site or a web page on the web site based on information derived from the acquired low latency web site traffic data for the web site.
According to another aspect of the disclosure, a system for reconfiguring a web site is described. The system includes a memory comprising low latency web site traffic data for a web site, and a processor. The processor is configured to automatically modify a layout or content of the web site or a web page on the web site based on information derived from the low latency web site traffic data for the web site. The low latency web site traffic data comprises web site traffic data that is received at a collecting server of the low latency web site traffic analytics service configured to collect the web site traffic data, and is pushed, from the collecting server to a real-time server of the low latency web site traffic analytics service configured to report the web site traffic data to a user, and any intermediate server configured to receive the web site traffic data in-between the collected server and the real-time server.
According to a further aspect of the disclosure, a graphical user interface for reconfiguring a web site is described. The graphical user interface includes a representation of a current configuration for a web site or a web page on the web site, and an identification of an automatic modification to the layout or content of the web site or the web page based on information derived from acquired low latency web site traffic data for the web site.
According to yet a further aspect of the disclosure, a machine-readable medium comprising instructions stored therein, which when executed by a machine, cause the machine to perform operations is described. The operations include acquiring low latency web site traffic data for a web site, and acquiring historical web site traffic data for the web site. The operations also include comparing the low latency web site traffic data and the historical web site traffic data, and automatically modifying a layout or content of the web site or a web page on the web site based on the comparison.
It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
The novel features of the subject technology are set forth in the appended claims.
However, for purpose of explanation, several configurations of the subject technology are set forth in the following figures.
The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, it will be clear and apparent to those skilled in the art that the subject technology is not limited to the specific details set forth herein and may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.
Several detailed embodiments of an exemplary multi-tiered system for receiving and reporting web site traffic data are described below. Section I provides a brief introduction to an exemplary multi-tiered system architecture for receiving and reporting web site traffic data of some embodiments. Section II describes an exemplary multi-tiered system architecture for receiving and reporting web site traffic data of some embodiments. Section III then describes exemplary processing of web site traffic data for temporary or persistent storage of some embodiments. Next, Section IV describes exemplary attributes and data structures used in the multi-tiered system of some embodiments. Section V describes an exemplary software architecture of a real-time analytics server of some embodiments. Section VI describes exemplary front-end web site traffic data reporting of some embodiments. Lastly, Section VII describes an exemplary electronic system, which implements some embodiments of the subject technology.
I. Introduction
Current analytics systems provide for aggregating and reporting of web site traffic data with high latency that can range from several hours to over a day. To address these issues with high latency, a real-time analytics system for receiving and reporting web site traffic data with low latency is provided. The real-time analytics system detects real-time web site traffic data for a web site in order to determine whether to automatically reconfigure the web site.
The real-time analytics system aggregates and reports web site traffic data by segmenting web site traffic data into one or more aggregation tables for presenting the web site traffic data in a useful and substantially real-time manner. In some implementations, a real-time server performs automated segmenting of tracking data included in a web site tracking data communication over a rolling window of time. Once a web site tracking data communication is routed to a real-time server, the real-time server 1) segments the web site tracking data communication according to one or more aggregation tables and 2) stores and/or updates the included tracking data (e.g., a user identifier, an event statistic(s), such as a timestamp of the current web page web site tracking data communication, and user data, such a city or other geographical location of the user) into one or more aggregation table(s) according to a predetermined query. The real-time server of some configurations can also perform an additional operation(s) on the segmented data, such as continually sorting the segments of tracking data within each of the aggregation tables to report the top segments of the tracking data from those aggregation tables.
By way of example, for a query that requests a number of hits per city per second, the real-time server can store the tracking data by time stamp in an array data structure, and for each array element include a pointer or hash key to a respective aggregation table. Data in the aggregation table can include any associated data included with the tracking data. For example, the aggregation table can include data representing 1) a geo-location and 2) a number of associated hits in each row that is segmented by a predetermined time (e.g., seconds). The real-time server can then rank the data in the aggregation table based on a particular criterion or criteria and select particular rows of the table for presentation (e.g., to a web front-end or any other type client).
To use a web site analytics data system, a publisher typically provides tracking instructions embedded in the web site's web pages (alternatively or conjunctively, by providing code in its web page that requests the tracking instructions from an analytics server). Typically, the tracking instructions are a small region of JavaScript™ code that the publisher includes in each page of the publisher's web site for which traffic is to be tracked. When a web page is rendered by a user device and/or client (e.g., web browsers, mobile devices, tablet devices, thin clients, thick clients, etc.), the tracking instructions are executed, which collects visitor data related to one or more different user sessions and sends it back to a real-time analytics server in the form of a web site tracking data communication for processing. One method of sending the web site tracking data communication is to send it as part of a Hypertext Transfer Protocol (HTTP) request.
II. Multi-Tiered System Architecture
Web site traffic data can be in the form of the aforementioned web site tracking data communications (e.g., Hypertext Transfer Protocol (HTTP) requests that are generated from various user devices and/or clients). Each web site tracking data communication can be triggered upon loading of a web page or resource (e.g., image file, banner ad, audio file, etc.) on the web site by a particular visitor to a publisher's web site. For the purpose of web site analytics reporting, the associated web site tracking data (e.g., included in associated HTTP requests) can include a web property ID (e.g., an account identifier that identifies a publisher's analytics account of a particular web site), visitor identity data (i.e., corresponding to a particular user session), an event statistic(s) (such as a timestamp of the current web page communication), and user data such as location data (i.e., geographical information) associated with the visitor to the publisher's web site. The amount and types of events/information that are reported in the tracking data can be specified by the publisher (e.g., to account for particular information that a publisher wishes to track as web site analytics data).
A multi-tiered real-time analytics system as described herein can be configured to receive and process incoming web site tracking data communications as described above to enable real-time reporting of web site analytics data with low latency. As used herein and discussed in further detail below, the term “real-time” corresponds with reporting web site analytics data within a specified deadline by pushing/transmitting the web site analytics data through different tiers of the multi-tiered real-time analytics system. The expression “low latency” as used herein can be therefore understood as a measurement of time that covers a time period from the reception of a web site tracking data communication to the real-time reporting of the web site analytics data included therein. For instance, in certain aspects, low latency web site traffic data includes web site traffic that is received from a network at a collecting tier, and is pushed, from the collecting tier to a reporting tier (or “real-time tier”), and any intermediate tier in-between the collecting tier and the reporting tier. As illustrated in
A real-time system is subject to a “real-time constraint” that can impose operational deadlines from an event to a system response. Thus, a real-time system operates within constraints on response time. In the context of the multi-tiered real-time analytics system, the flow of event tracking data through different tiers of the system is required to meet deadlines in order to report the data within a specified period of time (e.g., in a real-time manner with low latency). In one example, the real-time analytics system imposes a respective one second deadline for processing event tracking data within each tier of the system. For instance, upon receipt of an event tracking data communication, a logging server (e.g., in a logging tier described further below) must forward the event tracking data communication within a one second deadline to a real-time server (e.g., in a real-time analytics tier described below). In the event that the logging server can not meet the one second deadline, the event tracking data communication is dropped (e.g., discarded) by the logging server and no further processing occurs for that event tracking data communication. Similarly, when the real-time server receives the event tracking data communication from the logging server, the real-time server must forward the event tracking data communication to another real-time server or a front-end server (as described below) within a one second deadline. The real-time server similarly discards the event tracking data communication if it cannot meet the one second deadline. The one second deadline discussed above is just one example of the specified period of time. Other periods of time may be specified. In addition, each tier of the real-time analytics system may have a different specified period of time for processing an event tracking data communication.
As illustrated, the multi-tiered real-time analytics system 100 may further include a collecting tier 110, a logging tier 120, a persistent tier 130, a real-time analytics tier 140 and a front-end tier 150. Each of the aforementioned tiers can include a respective cluster of servers/computers that perform a same set of functions in a distributed and/or load balanced manner. A cluster can be understood as a group of servers/computers that are linked together to seamlessly perform the same set of functions, which can provide performance, reliability and availability advantages over a single server/computer architecture. For the sake of simplicity, each illustrated tier depicts several number of servers. However, one of ordinary skill in the art would realize that the illustrated tiers could include any number of servers and still be within the scope of the subject technology. The descriptions of the various tiers of the system 100 are explained in further detail below.
In some configurations, the collecting tier 110 receives incoming web site tracking data communications from the network 105. The collecting tier 110 includes at least one collecting server that is configured to receive and forward the web site tracking data communication. Each collecting server of the collecting tier 110 can process an incoming web site tracking data communication to determine a particular server in the logging tier 120 to route the web site tracking data communication. In some implementations, the collecting server can utilize a load balancing technique to determine which logging server in the logging tier 120 to route the web site tracking data communication. The load balancing technique can be based upon different factors such as server load, network load, and/or any other suitable computing metric for measuring resource utilization at a particular server.
The logging tier 120 can receive a routed web site tracking data communication from a particular collecting server of the collecting tier 110. Upon receiving the web site tracking data communication, the subsequent tasks of the logging tier 120 can be understood as being two-fold: 1) route received web site tracking data communications to the persistent tier 130 for persistent storage (e.g., of “historical” or “conventional” web site tracking data) and 2) route received web site tracking data communication to the real-time analytics tier 140 for temporary storage (e.g., of “low latency” or “real-time” web site tracking data).
To accomplish the aforementioned tasks, the logging tier 120 includes at least one logging server that is configured to receive the routed web site tracking data communication from the collecting server. In some implementations, the logging server aggregates incoming web site tracking data communications and then periodically routes the aggregated web site tracking data communications to the persistent tier 130 for persistent storage. Each web site tracking data communication is associated with a particular web site of a publisher and the aggregated web site tracking data communications can originate from disparate associated web sites and/or the same web site. In some implementations, the logging server can be further configured to verify each routed web site tracking data communication to guarantee delivery of the web site tracking data communications to a particular long-term storage server in the persistent tier 130.
For persistent storage of the web site tracking data communication, the persistent tier 130 of some configurations can include at least one long-term storage server. Each long-term storage server includes a non-volatile storage device(s), a database(s), or other similar non-volatile storage medium for persistent storage of an incoming web site tracking data communication. Persistent storage as used herein can be understood as referring to a type of non-volatile storage that stores the web site tracking data in a reliable manner. In some configurations, persistent storage can include lossless or near-lossless storage in which the data is stored without being deleted and/or replaced at a subsequent time period. Additionally, persistent storage can be characterized as storing web site tracking data in a form of historical records so that the system can extract the stored tracking data at a later period of time. In some configurations, the stored web site tracking data can be modified at a later time period. Alternatively, the stored web site tracking data can be in the form of immutable records (i.e., data that is not modified after being stored).
To improve the reliability of the persistent storage, some implementations of the persistent tier 130 can replicate the stored web site tracking data across another long-term storage server so that the tracking data is mirrored in at least one other long-term storage server. For instance, the long-term storage server that receives a particular web site tracking data communication can then undergo a replication process (either initiated by the long-term storage server itself, a second long-term storage server, or another server in the multi-tiered system) to copy (i.e., replicate) the particular web site tracking data to another long-term storage server. Data redundancy can therefore be provided to enable fault tolerance in the event the data stored at one long-term storage server is corrupted and/or lost.
To meet the low latency requirements for a multi-tiered real-time analytics system, the system can employ a lossy scheme for reporting web site traffic data in which some loss of web site tracking data is tolerated. In particular, because the web site tracking data is stored in persistent storage as described above, the multi-tiered real-time analytics system can adopt certain trade-offs for the sake of minimizing latency when routing the web site tracking data to the real-time analytics tier as described further below.
Each logging server of the logging tier 120 is further configured to route web site tracking data communications to the real-time analytics tier 140 for temporary storage. Given the requirement of low latency (i.e., minimizing latency in the system) connected with reporting real-time analytics data, each logging server can be configured to route the web site tracking data communications to the real-time analytics tier 140 at a greater frequency than routing the communications to the persistent tier 130. In some implementations, routing the tracking data communications to the real-time analytics tier 140 can be understood as occurring asynchronously with routing the communications to the persistent tier 130.
The real-time analytics tier 140 includes at least one real-time server that is configured to receive the routed web site tracking data communication from the logging tier 120. The real-time server in some implementations is configured to aggregate and/or sort the web site tracking data according to one or more predetermined criteria for real-time reporting of the web site analytics data to a publisher. As described before, each web site tracking data communication can include visitor identity data corresponding to a user session, location data associated with the user/visitor, and a timestamp corresponding to the visitor action.
The real-time server of some implementations can process the aforementioned data to generate real-time analytics data for temporary storage. For instance, the real-time server can aggregate and sort the location data according to the timestamp of the visitor action and then temporarily store the aggregated and/or sorted real-time analytics data. One of ordinary skill in the art would appreciate that other criteria can be used for aggregating and sorting the real-time analytics data. In one aspect, the real-time server sends the aggregated and/or sorted real-time analytics data to the front-end tier 150 for reporting the real-time analytics data. Moreover, as used herein, temporary storage can be understood as providing volatile, quick access to data (in comparison to persistent storage) stored in a storage device such as volatile memory (e.g., random access memory).
Alternatively to the above, the front-end tier 150 in one aspect can run queries on the stored real-time analytics data to report to the publisher with low latency. For instance, the real-time server can be configured to process incoming queries from the front-end tier 150 on the stored real-time analytics data. The real-time server can return matching real-time analytics data based on the queries to the front-end tier 150 for real-time presentation with low latency.
In some implementations, the system 100 includes the front-end tier 150, which includes at least one front-end server configured to report the real-time analytics data with low latency. As described above, the front-end server of some implementations is configured to receive real-time analytics data from the real-time server. By way of example, the front-end server can receive real-time web analytics data associated with a particular location (e.g., city, state, country, etc.) over a predetermined time period for presentation at a front-end interface (i.e., graphical user interface) to an end-user. One of ordinary skill in the art would understand that any set of real-time analytics data could be received for reporting the analytics data in a real-time manner.
Although the above description provides that system 100 includes several tiers, one of ordinary skill in the art would appreciate that in some configurations respective tiers could be combined to function as a single tier and still be within the scope of the subject technology. For instance, the above described collecting and logging tiers could be implemented as a single tier that perform a combined set of functions.
Moreover, to facilitate communication between the respective tiers as described above, the respective tiers can be configured to communication over a type of network, such as a local area network, a wide area network, or an interconnected network of networks (e.g., the Internet) and by using any sort of network/communications protocol (Transmission Control Protocol and Internet Protocol (TCP/IP), HTTP, etc.).
In addition, different configurations of the multi-tiered system can be organized in different ways. For instance, different tiers could be located in different geographical locations. Each geographical location can be associated with a respective data center that includes one or more servers associated with a particular tier. Alternatively or conjunctively, the respective servers in one particular tier could be located in one or more different geographical locations and/or data centers. This flexibility in organizing the multi-tiered system provides an advantage of increasing the scalability of the system to include servers across potentially disparate physical locations.
III. Processing of Web Site Tracking Data Communications
In the following section, respective exemplary processes for routing a web site tracking data communication to a real-time server and processing the tracking data communication by the real-time server are described in further detail.
The process 200 starts when a web site tracking data communication is received at 205. By reference to
The process 200 can then perform the task of routing the received web site to separate tiers. At 210, the web site tracking data communication is routed to a long-term storage server (e.g., in the persistent tier 130 from
The process 200 then continues to 215 to route the web site tracking data communication to a selected real-time server. Referring to
Additionally, the process 200 at 215 can route the web site tracking data communication at a greater frequency than routing the communication to the long-term storage server. For example, when the logging server receives the web site tracking data communication, the logging server can queue several tracking data communications before sending them to the long-term storage server because low latency is not a factor for the aspect of the multi-tiered system dealing with persistent storage of the web site tracking data. In one aspect, the logging server can immediately or in a shorter time period route the web site tracking data communication to the randomly selected real-time analytics server to ensure that the requirement of low latency processing, storing and reporting of the real-time analytics data is met. After routing the web site tracking data communication to the long-term storage server and the real-time server, the process 200 then ends.
Although the above description of the process 200 describes that routing to the long-term storage server occurs before routing to the real-time server, one of ordinary skill in the art can appreciate that the described order is one exemplar and some implementations could reverse the order of the previously described routing without departing from the scope of the invention. For instance, some implementations could route the web site tracking data communication to the real-time server before routing the communication to the long-term storage server. In another aspect, routing the communication to the long-term storage server and the real-time server occurs in a simultaneous and/or synchronous manner.
The following discussion describes an exemplary process for processing and storing a web site tracking data communication received by an arbitrarily selected real-time server. In some configurations, after the web site tracking data communication is routed to the arbitrarily selected real-time server as described above in
The process 300 begins when a routed web site tracking data communication is received at 305 in a selected real-time server. For instance, the real-time server can receive the web site tracking data communication when the communication is pushed from the logging server to the real-time server. As similarly discussed above in connection with
At 310, the process 300 determines the real-time server(s) associated with the web site tracking data communication. In some implementations, a real-time server(s) can be associated with a web site of a particular publisher. For instance, the real-time server can consult a table, list or other suitable data structure that indicates one or more real-time servers that are associated with the publisher's web site. The associated one or more real-time servers therefore can be considered an “owner” of any web site tracking data communication for that publisher's web site. In practical terms, when acting as the owner, the associated real-time server is required to process each web site tracking data communication for that publisher's web site. Based on the determination at 310, the process 300 can decide at 320 whether a different real-time server is associated with the received web site tracking data communication.
In an instance in which the process 300 determines at 320 that the real-time server is not associated with the web site tracking data communication, the process 300 continues to 330. At 330, the process 300 routes the web site tracking data communication to one or more real-time servers associated with the web site tracking data communication based on the determination at 310. Referring to
Alternatively, in an instance in which the process 300 determines at 320 that the real-time server is associated with the web site tracking data communication, the process 300 continues to 340 to temporarily store real-time analytics data based on the web site tracking data communication. A more detailed description of exemplars of the real-time analytics data will be discussed below in connection with
Although the above description describes that the process 300 determines an associated owner of the web site tracking data communication at 320, one of ordinary skill in the art can appreciate that in some implementations this step is not performed (i.e., process 300 foregoes 310-330) and the process 300 immediately proceeds to 340 to store the web site tracking data communication. In such implementations, the real-time server that receives the communication assumes ownership of the received communication.
IV. Real-Time Analytics Data Structure
The following section describes exemplar attributes and data structures of the real-time analytics data. An associated real-time server can temporarily store such attributes and data structures illustrated in
In some implementations, the real-time analytics data structure 400 can be understood as a container that is a collection of the various attributes and data structures based on one or more web site tracking data communication(s). As shown in
As illustrated, the associated web property identity (WPID) data structure 410 includes one or more associated WPID attributes. Each associated WPID attribute can represent a publisher of a web site that is associated with the real-time server. As shown, the associated WPID attribute 420 corresponds with a publisher with a “WPID 1” that represents a unique string ID for the publisher. One of ordinary skill in the art would understand that the unique string ID could be formed from any combination of alphanumeric characters and/or symbols.
In some implementations, each associated WPID attribute can include a reference to the visitor data structure 430. The visitor data structure 430 includes attributes for each unique visitor to the publisher's web site. As shown, the visitor data structure 430 includes visitor data element 440 corresponding to “Visitor X” for the publisher corresponding with associated WPID attribute 420. The visitor data element 440 is shown in more detail in breakout section 450.
As further shown in
Next, the last timestamp attribute of the visitor real-time data attributes 450 represents the most recent timestamp in which the unique visitor visited the publisher's web site. A timestamp in some implementations is a sequence of alphanumeric characters that denotes the date and/or time in which a particular event occurred. The location data attribute represents the geographical location of the unique visitor, such as a specified city, state, county, country, zip code, global positioning system coordinates, and/or geographical coordinates (e.g., latitude, longitude, and elevation), etc. Lastly, the campaign attribute identifies a particular marketing campaign corresponding with a set of associated marketing activities. For instance, the associated marketing activities can respectively correspond to a set of web pages on the publisher's web site. Any visitor activity/action related to the set of web pages on the publisher's web page can then be associated with the marketing campaign. In this manner, the campaign attribute can identify the marketing campaign associated with the visitor action.
The visitor real-time data attributes 450 in visitor data element 440 can include a reference to the visitor action data structure 460. The visitor action data structure 460 can include attributes for identifying an associated action with a particular timestamp. As shown, the visitor action data structure 460 includes several attributes from a timestamp A for a request URI A to a timestamp N for a request URI N. A URI stands for a Uniform Resource Identifier, which can be formed from a string of alphanumeric characters to represent a resource on the publisher's web site. A resource can represent any form of data accessed from the publisher's web site by a visitor action (e.g., accessed through a web browser or similar type of application for display on a user device). Hence, the visitor action data structure 460 granularly records associated visitor actions to a resource per timestamp in one exemplar.
Different implementations can implement and organize the above described attributes and data structures in different ways. For instance, the real-time analytics data structure 400 of some configurations can be implemented as a collection of tree data structures, otherwise known as a “forest.” In this exemplar, a root node of a particular tree corresponds with a particular WPID (i.e., publisher identity) and each direct child of the root node can represent multiple visitor nodes that are associated with respective visitors to the publisher's web site. For each visitor node, visitor specific attributes are stored. Each visitor node can have multiple direct child nodes that represent the associated visitor's actions based on a timestamp. The timestamp of the last action for the associated visitor can also be stored with the parent associated visitor node described above. Alternatively or conjunctively, certain visitor attributes can be implemented as discrete nodes, such as a node including a city identifier with respective direct child nodes corresponding to a city name and geographical coordinates (e.g., latitude, longitude, etc.).
The following description describes an exemplary process for segmenting incoming web site tracking data communications according to a predetermined aggregation table over a rolling window of time. In some instances, an administrator of the multi-tiered analytics system can set one or more different aggregation tables for storing different data from the incoming communications received during a specified period of time. Incoming web site tracking data communications can be processed in order to extract relevant data into such aggregation tables. Each aggregation table can include corresponding web site tracking data that is frequently searched/queried in reporting real-time analytics data. For instance, data related to a derived location (e.g., based from an associated Internet Protocol address from an Internet service provider), a uniform resource locator or identifier (e.g., a web page address), or an ad source (e.g., referrer) can be placed into one or more different aggregation tables.
In some instances, an administrator of the multi-tiered analytics system can set the order in which the aggregation tables are searched. In particular, the administrator can configure the system so that aggregation tables containing data that is reported more often are searched before aggregation tables containing data that is searched and reported less frequently. It should be understood that system latency can be reduced because more frequently reported data is initially searched and/or located, which reduces processing time because the system forgoes searching unlikely matching data. Thus, the multi-tiered analytics system enables prioritization in searching/querying of the web site tracking data to improve latency in reporting the web analytics data.
Alternatively or conjunctively, a predetermined query can be configured by a publisher for segmenting web site tracking data from incoming web site tracking data communications according to different needs of the publisher. In some instances, the utilization of the predetermined query can require the creation of a custom aggregation table for storing the type of data according to the predetermined query. Similarly, the exemplary process described below can place the segmented tracking data into one or more different aggregation tables (e.g., tables that are created before the predetermined query as described above). For example, the publisher can configure the predetermined query to segment the web site tracking data according to different user information and/or different visitor actions. By way of example, the publisher could be interested in segmenting each geographical location associated with respective web page requests or segmenting the web site tracking data to track a number of requests to a particular web page resource (e.g., banner ad, image, etc.). The segmented web site tracking data based on the predetermined query can be subsequently reported to the publisher in a real-time manner. By configuring one or more different predetermined queries, time can be saved in reporting web site tracking data by reducing the administrative costs with managing the real-time analytics system.
V. Real-Time Analytics Software Architecture
To organize the web site tracking data into a contextually meaningful format for reporting the real-time analytics data with low latency, the exemplary process described below can segment the web site tracking data communication into one or more aggregation tables.
The process 500 starts when a web site tracking data communication is received at 505 during a span of time. The span of time in some configurations corresponds with a time interval during which web traffic data in the form of a web site tracking data communication(s) is received by the multi-tiered analytics system. By reference to
At 510, the process 500 can store the web site tracking data into a master table for a particular span of time. The master table of some configurations includes all data from the web site tracking data communication that could be utilized for real-time analytics reporting. The process 500 could utilize the master table for different operations. For instance, in a scenario in which the process 500 requires different data than data currently included in existing aggregation tables (e.g., to satisfy a new user-defined query), the process 500 could search the master table for such data and form a new aggregation table to hold the data.
The process 500 at 515 segments the web site tracking data communication into one or more aggregation tables. To accomplish this task, the process 500 can extract corresponding web site tracking data included in the communication and place the extracted data into one or more aggregation tables. As discussed above, each aggregation table can include commonly searched for data for real-time analytics reporting, or include data according to a respective predetermined query (i.e., a user-defined query). The predetermined query of some configurations organizes the web site tracking data based on one or more different criterion for an associated web property ID of a publisher's web site. For instance, the predetermined query can be based on user data, such as a city or other geographical location of the user. By way of example, the process 500 of some configurations segments the web site tracking data communication according to a predetermined period of time for a respective associated web property ID of a publisher. In particular, the process 500 can utilize a time stamp of the web site tracking data communication in order to determine the one or more aggregation tables in which the tracking data is segmented.
After segmenting the web site tracking data, the process 500 at 520 updates the one or more aggregation tables with the segmented web site tracking data. For instance, the process 500 can update one or more different entries in a particular aggregation table. In an example in which the particular aggregation table tracks a number of occurrences for a particular event or visitor action, the process 500 can increment a respective number/count for a particular tracked event such as a number of hits in a corresponding entry of the aggregation table. For each incoming web site tracking data communication over the rolling window of time, the process 500 continuously updates corresponding entries in one or more aggregation tables to facilitate real-time analytics reporting of the web site tracking data with low latency.
The process 500 then continues to 525 to determine whether an additional operation(s) is to be performed on the web site tracking data. If an additional operation is performed, then the process 500 continues to 530 to perform the additional operation, otherwise the process 500 ends. Some configurations can perform filtering (e.g., removing/reducing data), sorting (e.g., ranking) and other types of processing operations on the web site tracking data. For instance, the process 500 can rank the segmented web site tracking data to organize the web site tracking data into a specified order (e.g., most occurrence, most significant, etc.) by sorting the segmented web site track data. In an example in which the aggregation table tracks the corresponding number of hits for events or visitor actions, the process 500 can sort the segmented web site tracking data according to the number of hits (e.g., ascending or descending numerical order). Alternatively, the process 500 can sort the segmented web site tracking data based on a non-numerical criterion (e.g., alphabetical order), such as sorting the geographical locations respectively associated with the web site tracking data in the aggregation table.
Additionally, the process 500 of some configurations can employ intelligent ranking at 530 by computing and/or assigning weights to the segmented data. One or more different factors can determine an assigned weight such as a web page associated with the visitor activity (e.g., more important pages are assigned higher/greater weight), the type of visitor activity (e.g., browsing, commenting, etc.), referrer (e.g., where the visitor came from), etc. Hence, it can be understood that the web site tracking data can be qualitatively ranked according to one or more different assigned weights to respective data. The process 500 can perform qualitative ranking of the segmented data in addition or alternatively to the quantitative ranking described above.
In some configurations, the process 500 can transmit at 530 the segmented web site tracking data in the corresponding aggregation table to a front-end server for reporting the web site tracking data. By way of example, the process 500 can receive a query from the front-end server for the web site tracking data and, in response, can transmit data that matches the query to the front-end server. Alternatively or conjunctively, the process 500 can be configured to push data from one or more aggregation tables to the front-end server without requiring the front-end server to request the data. The process 500 then ends.
Although the process 500 is described in
The following description discusses exemplary data structures utilized by the process 500 described above in
Each time interval shown in
As shown, the time interval 610 has several associated aggregation tables 630, 635, 640 and a master table 625. The master table 625 is formed during the time interval 610 to store all data from each received web site tracking data communication during the time interval 610. In some configurations, the real-time analytics system can utilize the master table in the event that the desired web site tracking data is not available in any other associated aggregation table for the time interval 610. In this instance, the real-time analytics system can search/query the master table to create a new aggregation table to store this newly segmented data. In some configurations, after this new aggregation table is created, an analogous new aggregation table is created for the each of the remaining time intervals. For example, new respective analogous aggregation tables in the time intervals 615 to 620 can be subsequently created by searching corresponding master tables for the desired web site tracking data.
The associated aggregation tables 630, 635 and 640 represent exemplary data structures for storing portions of data (i.e., segmented data) also included in the master table 625. Each aggregation table can include segmented data extracted from incoming web site tracking data communications. As illustrated, the aggregation tables 630, 635 and 640 respectively include tracking data related to a city (e.g., geographical location), web page (e.g., URL/URI string indicating a web address) and source of a referral (e.g., an ad source, HTTP referrer, etc.). The exemplary aggregation tables in
For each subsequent time interval, one or more aggregation tables can be utilized that are respectively analogous to the same aggregation tables used in a prior time interval. For instance, aggregation tables 650, 655 and 660 in the time interval 615, and aggregation tables 670, 675 and 680 in the time interval 620 respectively represent analogous data structures to the aggregation tables 630, 635 and 640 in the prior time interval 610. As shown, the aggregation tables 650, 655 and 660 respectively include P, Q and R number of entries, where P, Q and R are respective non-zero integer values. More specifically, the aggregation table 650 includes entries C1-C4 up to P entries that represent respective cities, the aggregation table 655 includes entries P1-P4 up to Q entries that represent respective pages, and the aggregation table 660 includes entries S1-S4 up to R entries that represent respective sources. Similarly, the aggregation table 670 includes entries C1-C4 up to S entries that represent respective cities, the aggregation table 675 includes entries P1-P4 up to T entries that represent respective pages, and the aggregation table 660 includes entries S1-S4 up to U entries that represent respective sources.
Although the above description of
The following description discusses an exemplary process for segmenting web site tracking data in discrete units of time according to some configurations. Segmenting the data according to units of time enables the multi-tiered analytics system to report real-time analytics data in a finely granulated manner. In other words, the real-time web site analytics data can be reported in segments corresponding to smaller units of time.
The process 700 starts when a web site tracking data communication is received at 705. By reference to
At 710, the process 700 determines a time stamp for the web site tracking data communication. As used herein, the term “time stamp” can be understood as a sequence of characters and/or symbols that indicates the date and/or time at which a particular event or visitor action occurred. In some instances, the process 700 can determine the time stamp as it is included in the web site tracking data communication as part of the incoming request.
The process 700 continues to 715 to determine a position in an array based on the time stamp for the received web site tracking data communication. In some configurations, the position in the array is determined by performing a modulo n operation on the time stamp, where n represents the size of the array. For instance, in an example where the size of the array is 60, the position in the array can be determined by performing a modulo 60 operation on the time stamp. In this example, it can be understood that the array includes sixty positions in which each position logically represents a respective second within a minute time period. The process 700 of some configurations therefore enables segmentation of the web site tracking data according to the size of the array, where each position in the array can be a logical representation of a specific division of time (e.g., second, minute, hour, etc.).
Based on the determined position, the process 700 at 720 compares the time stamp with a stored time stamp at the determined position in the array. For instance, some configurations respectively store associated time stamps for one or more positions in the array for incoming web site tracking data communications. Each stored time stamp can reference one or more different aggregation tables that segment the web site tracking data according to different respective predetermined queries.
Based on the comparison at 720, the process 700 can decide at 725 whether the time stamps match. In an instance in which the time stamps match one another, the process 700 at 730 stores the web site tracking data communication based on a particular predetermined query in an aggregation table referenced from the position in the array. Further, as discussed above in reference to
Alternatively, in an instance in which the time stamps do not match, the process 700 continues to 735 to clear (i.e., erase or delete) one or more (if any) stored web site traffic data entries in the aggregation table referenced from the position in the array. The process 700 at 740 stores the time stamp at the position in the array. At 745, the process 700 then stores the web site traffic data communication in the aggregation table referenced from the position in the array according to the predetermined query. The process 700 then ends.
In some configurations, the array is referenced from an associative array with one or more entries. One form of an associative array can be a hash table with one or more entries. Each hash table entry can represent a respective web property identity for a particular publisher. The expression “hash table” as used herein can be understood as a data structure including one or more unique keys and corresponding one or more values in which each key is associated with one or more values. In this manner, a hash table of web property identities can be provided to enable segmenting the data according to an associated publishers web property identity (e.g., for a particular web site).
Although an associative array is described above, one of ordinary skill in the art would realize other data structures can be utilized and still be within the scope of the subject technology. By way of example, some configurations can use binary search trees and/or linked lists of key/value pairs for referencing the above described array.
The following discussion describes exemplary data structures that could be used by the processes 500 and 700 described above in
As shown in
A particular entry in the array 810 can include a reference to a corresponding aggregation table. For instance, as illustrated in
As illustrated, the aggregation table 820 includes segmented web site tracking data based on the geographical location (i.e., the city) associated with the web site tracking data. In this example, the aggregation table 820 includes two columns for one to Y entries corresponding to respective geographical locations and an associated number/count of hits. In other words, the aggregation table 820 keeps a count of hits/requests for each geographical location. Referring to
The following section describes a software architecture of a real-time server that can implement the above described processes and data structures as a computer program running on a particular machine, such as a computer, or stored as instructions in a computer readable medium.
As illustrated in
The real-time server 905 can receive web site tracking data 902 in a request router module 910. The web site tracking data 902 can be in the form of a web site tracking data communication that is received over a network 950. As shown, the request router module 910 includes a parser module 912 and an ownership module 914. The parser module 912 of some implementations can parse the web site tracking data to extract real-time analytics data and to subsequently transmit the real-time analytics data to the ownership module 914. The ownership module 914 determines a set of associated real-time servers that are owners of the web site tracking data corresponding with a publisher's web site. In an instance where the ownership module 914 determines that the web site tracking data 902 is not associated with the real-time server 905, the request router module 910 can route the web site tracking data 902 over the network 950 to other associated real-time servers. As shown in
The hit accumulator module 920 receives the web site tracking data routed from the request router module 910. In some implementations, the hit accumulator module 920 includes a buffer module 922 as shown for queuing/aggregating the web site tracking data. The buffer module 922 can be implemented in different ways. For instance, the buffer module 922 could utilize a first-in first-out (FIFO) scheme in which the earliest received web site tracking data is transferred out before later received data. In other instances, the buffer module 922 could employ a last-in first-out (LIFO) scheme that is analogous to a stack in which the later received data is transferred out before earlier received data.
As shown in
In some implementations, the hit accumulator module 920 can execute queries for sorting and/or aggregating the received web site tracking data for temporary storage in the real-time analytics data storage 930. For instance, referring back to
Moreover, the hit accumulator module 920 can be configured to segment the received web site tracking data into one or more different aggregation tables. For instance, referring back to
VI. Front-End Web Site Traffic Data Reporting
The real-time analytics query engine 924 of the hit accumulator module 920 can execute queries to obtain event tracking data such as real-time web site tracking data (e.g., real-time web site traffic data) for a web page within a web site. Although web site tracking data is referred to synonymously with event tracking data in the discussion of
As discussed above with reference to
The process 1000 at 1005 acquires real-time web site traffic data for a web site. The web site traffic data can be of various types. Exemplary types of web site tracking data include time data (e.g., a current rate of web traffic), geo-location data (e.g., current web traffic from one geographic location), and activity type data (e.g., current activities of visitors on a web page). Source data (e.g., current referrers to a web page) and target data (e.g., current destinations on a web page) can also be used. Visitor data (e.g., current unique viewers of a web page), visit data (e.g., current sessions of unique viewers of a web page), and hit data (e.g., current hits of a web page) can further be used. Yet further exemplary types of web site tracking data include advertisement data (e.g., current advertisement selections on a web page) and search term data (e.g., current search terms used to be directed to a web page).
In certain aspects, the web site is registered with a real-time web site traffic analytics service (e.g., the multi-tiered real-time analytics system 100). For instance, a publisher registers a web site with the real-time web site traffic analytics service by indicating to the real-time web site traffic analytics service that a web page or resource (e.g., a small blank image file) linked to the real-time web site traffic analytics service has been placed on a web page within the web site. The real-time web site traffic data can be obtained by the hit accumulator module 920 using queries. Specifically, the hit accumulator module 920 can use a query to obtain, for a web page within a web site registered with the multi-tiered real-time analytics system 100, real-time web site tracking data temporarily stored in the real-time analytics tier 140. The queries executed by the hit accumulator module 920 can be pre-configured queries associated with the aggregation tables or incoming queries from the front-end tier 150. The incoming queries from the front-end tier 150 include user-defined queries that are executable at the time the user defines the query, such that the user receives real-time web site traffic data substantially immediately in response to defining and submitting the user-define query. The incoming queries from the front-end tier 150 also include previously defined user queries that are saved by the front-end tier 150 for later or repeated execution by the real-time analytics query engine 924.
At 1010, the process 1000 automatically modifies a layout or content of the web site or a web page on the web site based on the acquired low latency web site traffic data for the web site. For instance, an article or a sale item on a web site may be receiving more or less activity than it previously received. As such, the system may move a more active article or sale item to a more prominent position on the web site and move a less active article or sale item to a less prominent position on the web site. Specifically, at 1010, after obtaining the real-time web site tracking data, the hit accumulator module 920 can push the real-time web site tracking data for the web page to the front-end tier 150. The front-end tier 150 can determine whether to modify the layout or content of the web site or web page based on a comparison of real-time web site traffic data for a first portion of the web site (e.g., a section of a web page) with real-time web site traffic data for a second portion (e.g., another section of the web page) of the web site. As discussed herein “automatic modification” includes programmed instructions executed by a processor to modify the layout or content of the web site or a web page in response to a determination made regarding the low latency web site traffic data. In certain aspects, the modification is automatically made in response to the determination regarding the low latency web site traffic data.
The front-end tier 150 can also determine whether to modify the layout or content of the web site or web page based on a comparison of real-time web site traffic data with historical web site tracking data from the persistent tier 130. For instance, the automatic modification of the layout or content of the web site or the web page can be in response to an identification of a web site traffic data anomaly determined based on the comparison of the low latency web site traffic data with the historical web site traffic data. An anomaly can be detected by comparing real-time web site tracking data for the web page with historical web site tracking data for the web page.
The real-time analytics query engine 924 can use queries to process web site tracking data (e.g., web site traffic data) in order to identify anomalies in web site traffic can using various anomaly detection techniques. The techniques include identifying an anomaly using thresholds and/or statistics. Various statistical considerations include frequencies, percentiles, means, variances, covariances, and standard deviations. For instance, the real-time analytics query engine 924 can execute a query to identify an anomaly when historical web site tracking data shows an average hit rate per minute from Tokyo for a web site that is at least one standard deviation away from the current (i.e., real-time) average hit rate per minute from Tokyo for the web site. Other anomaly detection techniques can also be used, including rule-based systems (e.g., characterizing normal web site traffic using a set of rules and detecting variations therefrom). For instance, a rule is defined in a rule-based system that creates an exception for high web site traffic for e-commerce on pre-defined high web site traffic days, such as the day after Thanksgiving Day. On the day after Thanksgiving Day, the real-time analytics query engine 924 detects that the current (i.e., real-time) hit rate for an online shopping web site is ten times greater than the hit rate for the web site from the previous day, Thanksgiving Day. Although web site traffic has increased ten fold, the real-time analytics query engine 924 does not display information on the change of web site traffic within the graphical user interface due to the rule excepting high web site traffic for c-commerce web sites on the day after Thanksgiving. As a result, no modification is made to the web site configuration.
Another anomaly detection technique is profiling (e.g., building profiles of normal web site traffic behavior and detecting variations therefrom). For instance, a profile for normal web site traffic behavior indicates that there is greater web site traffic during the waking hours of 6:00 AM to 12:00 AM, and less web site traffic during the resting hours of 12:00 AM to 6:00 AM. Information on an anomaly is then displayed within the graphical user interface if there is significantly greater web site traffic during the resting hours than during the waking hours. Additional anomaly detection techniques include model based approaches (e.g., developing a model to characterize normal web site traffic and detecting variations therefrom), and distance based methods (e.g., by computing distances among points).
Exemplary types of web site tracking data that can be used in anomaly detection include time data (e.g., comparing a current rate of web traffic with a historical rate of web traffic over a certain period of time), geo-location data (e.g., comparing current web traffic from one geographic location with historical of web traffic from that geographic location), and activity type data (e.g., comparing current activities of visitors on a web site with historical activities of visitors on the web site). Source data (e.g., comparing current referrers to a web site with historical referrers to the web site) and target data (e.g., comparing current destinations on a web site with historical destinations on the web site) can also be used in anomaly detection. Visitor data (e.g., comparing current unique viewers of a web site with historical unique viewers of the web site), visit data (e.g., comparing current sessions of unique viewers of a web site with historical sessions of unique visitors of the web site), and hit data (e.g., comparing current hits of a web site with historical hits of the web site) can further be used in anomaly detection. Yet further exemplary types of web site tracking data include advertisement data (e.g., comparing current advertisement selections on a web site with historical advertisement selections on the web site) and search term data (e.g., comparing current search terms used to be directed to a web site with historical search terms used to be directed to the web site).
Once a determination is made to modify the layout or content of the web site or the web page based on the acquired low latency web site traffic data, the modification can occur in a variety of ways. In certain aspects, the layout or content of the web site can be modified. For instance, if the web site, web page, article, sale item, etc., is receiving an increase or decrease in web traffic, a request for an increase or decrease in bandwidth or other resources, such as additional servers or processing capacity, can automatically be generated (e.g., by an account associated with the publisher to the web site host). Similarly, as discussed above, in the web site is receiving an increase in web traffic related to particular content, the site map for the web site can be modified to make the particular content more accessible, such as by renaming files for web pages, moving the files to higher level directories, and/or associating the files as the default index files in directories.
In certain aspects, the layout or content of a web page from the web site can also be modified. Content, such as text, images, and hyperlinks can be added to or removed from the web page. For instance, if the low latency web site traffic data indicates that a certain sports team is increasing in web traffic popularity, then an article on the sports team can be added to the web page. If the low latency web site traffic data indicates that a certain sports team is no longer popular, then an article on the sports team can be removed from the web page or moved to a less prominent location so as to not take up more important real estate on the web page with less active or interesting content. Similarly, if certain content, such as hyperlinks, related to a sports team that is increasing in web site traffic popularity is featured at a less prominent position (e.g., at the bottom and/or to the right) on a web page, the content can be moved to a more prominent position (e.g., at the top and/or to the left) on the web page, displacing or replacing other content, if necessary. The prominence of content can also be increased or decreased in other ways, and in response to the web site traffic popularity of the content. In addition to moving the position of the content, content can be highlighted, changed in size (e.g., font or image size), shape, or color.
Sound and/or animations can be associated with or removed from the content. Information on the modification made to a web site or a web page on the web site can be sent to a graphical user interface for display, as illustrated in
The user interface screenshot 1100 of
The web page includes illustrations of how the layout of a web page has been reconfigured based on real-time web site traffic data from a previous version 1106 to a current version 1108. The previous version 1106 of the web page indicates that a less popular item, Item A 1110, as located at a prominent location on the web page and a more popular item. Item E 1112, was located at a less prominent location on the web page. An arrow 1114 on the illustration of the current version 1108 of the web page indicates the change in layout.
The user interface screenshot 1150 of
The publisher of the web site can use the information from the front-end user interfaces of
The front-end user interface of
VII. Electronic System
The following section describes an exemplary system that implements aspects of the above-described invention.
Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some implementations, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some implementations, the software programs, when installed to operate on one or more systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
The bus 1205 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the system 1200. For instance, the bus 1205 communicatively connects the processing unit(s) 1210 with the read-only memory 1220, the system memory 1215, and the storage device 1225.
From these various memory units, the processing unit(s) 1210 retrieves instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) can be a single processor or a multi-core processor in different implementations.
The read-only-memory (ROM) 1220 stores static data and instructions that are needed by the processing unit(s) 1210 and other modules of the system 1200. The storage device 1225, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the system 1200 is off. Some implementations of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the storage device 1225.
Other implementations use a removable storage device (such as a flash drive, a floppy disk, and its corresponding disk drive) as the storage device 1225. Like the storage device 1225, the system memory 1215 is a read-and-write memory device. However, unlike storage device 1225, the system memory 1215 is a volatile read-and-write memory, such a random access memory. The system memory 1215 stores some of the instructions and data that the processor needs at runtime. In some implementations, the invention's processes are stored in the system memory 1215, the storage device 1225, and/or the read-only memory 1220. For example, the various memory units include instructions for processing multimedia items in accordance with some implementations. From these various memory units, the processing unit(s) 1210 retrieves instructions to execute and data to process in order to execute the processes of some implementations.
The bus 1205 also connects to the optional input and output interfaces 1230 and 1235. The optional input interface 1230 enables the user to communicate information and select commands to the system. The optional input interface 1230 can interface with alphanumeric keyboards and pointing devices (also called “cursor control devices”). The optional output interface 1235 can provide display images generated by the system 1200. The optional output interface 1235 can interface with printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations can interface with devices such as a touchscreen that functions as both input and output devices.
Finally, as shown in
These functions described above can be implemented in digital electronic circuitry, in computer software, firmware or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.
Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray, discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions that are stored on the circuit itself.
As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.
To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.
Configurations of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some configurations, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.
It is understood that any specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged, or that all illustrated steps be performed. Some of the steps may be performed simultaneously. For example, in certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the configurations described above should not be understood as requiring such separation in all configurations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention.
A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A phrase such as a configuration may refer to one or more configurations and vice versa.
The word “exemplary” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.
Claims
1. A machine-implemented method for modifying a web site comprising:
- registering a web site comprising a resource with a real-time web site traffic analytics service comprising a real-time analytics tier,
- linking the resource to the analytics service;
- receiving a real-time traffic data for the resource;
- receiving a second real-time traffic data for a second resource;
- comparing the real-time traffic data for the resource with the second real-time traffic data for the second resource; and
- modifying the resource of the web site in response to the comparison.
2. The method of claim 1 further comprising
- limiting modifications that can be made to the web site, and where the modifying step comprises
- modifying the resource of the web site in response to the comparison within the limitations.
3. The method of claim 1 where the modifying step comprises one of renaming the resource, moving the resource to a higher or lower level directory of the web site, associating the resource as a default index file of a directory, or disassociating the resource as a default index file of a directory.
4. The method of claim 1 where the modifying step comprises adding, or removing the resource or a text, image, hyperlink, highlighting, shape, color, sound, or animations associated with the resource.
5. The method of claim 4 where the modifying step comprises changing the position or size of the resource or the text, image, hyperlink, highlighting, or animations associated with the resource.
6. The method of claim 1 where the modifying step comprises:
- detecting whether an anomaly exists based on the comparison; and
- modifying the web site in response to detecting the anomaly.
7. The method of claim 6 where the detecting step comprises:
- calculating at least one statistic from the comparison; and
- detecting an anomaly based on the statistic.
8. The method of claim 6 further comprising
- building either a profile or a model of a normal web site traffic behavior, and where the detecting step comprises
- detecting an anomaly based on the comparison applied to the profile or the model.
9. The method of claim 1 further comprising:
- alerting a user that a modification has been made to the web site;
- notifying the user the type of modifications made to the web site;
- sending the user a web site containing a pre-modified version of the web site as well as a modified version of the web site.
10. A system for modifying a web site, comprising:
- a registration module transmitting a registration message for a web site to a traffic analytics service;
- a linking module linking a resource on the web site to the service;
- a receiver module receiving a real-time traffic data of the resource and a second real-time traffic data for a second resource;
- a comparison module for comparing the real-time traffic data of the resource and the real-time traffic data for the second resource; and
- a modification module modifying the resource in response to the comparison.
11. The system of claim 10 where the registration module comprises receiving at least one limitation on the modifications that can be made to the resource, and the modification module comprises modifying the resource within the limitation in response to the received comparison.
12. The system of claim 10 where the modification module comprises:
- a detection module detecting whether an anomaly exists; and
- the modification module modifying the web site in response to the anomaly and the comparison.
13. The system of claim 12 where the detection module comprises:
- a calculation module calculating at least one statistic from the comparison; and
- the detection module detecting an anomaly based on the statistic.
14. The system of claim 12 further comprising: and where the detection module comprises
- a builder module building either a profile or a model of a normal web site traffic behavior,
- the detection module detecting an anomaly based on the comparison applied to the profile or the model.
15. The system of claim 10 further comprising:
- an alert module alerting a user that a modification has been made to the web site after the modification module modifying the web site;
- a notifier module notifying the user the type of modifications made to the web site after the modification module modifying the web site;
- a sender module sending the user a web site containing a pre-modified version of the web site as well as a modified version of the web site in response to querying the modification module.
16. A machine-implemented method for modifying a web site comprising:
- registering a web site comprising a resource with a real-time web site traffic analytics service comprising a real-time analytics tier;
- linking the resource to the analytics service;
- receiving a comparison of a real-time traffic data for the resource to a second traffic data;
- modifying the resource of the web site in response to the comparison;
- alerting a user that a modification has been made to the web site;
- notifying the user the type of modifications made to the web site; and
- sending the user a web site containing a pre-modified version of the web site as well as a modified version of the web site.
17. The method of claim 16 further comprising
- limiting modifications that can be made to the web site, and where the modifying step comprises
- modifying the resource of the web site in response to the comparison within the limitations.
18. The method of claim 16 where the receiving step comprises:
- receiving a real-time traffic data for the resource;
- receiving a historic traffic data for the resource; and
- comparing the real-time traffic data with the historic traffic data.
19. The method of claim 16 where the modifying step comprises one of renaming the resource, moving the resource to a higher or lower level directory of the web site, associating the resource as a default index file of a directory, or disassociating the resource as a default index file of a directory.
20. The method of claim 16 where the modifying step comprises adding, or removing the resource or a text, image, hyperlink, highlighting, shape, color, sound, or animations associated with the resource.
21. The method of claim 20 where the modifying step comprises changing the position or size of the resource or the text, image, hyperlink, highlighting, or animations associated with the resource.
22. The method of claim 16 where the modifying step comprises:
- detecting whether an anomaly exists based on the comparison; and
- modifying the web site in response to detecting the anomaly.
23. The method of claim 22 where the detecting step comprises:
- calculating at least one statistic from the comparison; and
- detecting an anomaly based on the statistic.
24. The method of claim 22 further comprising
- building either a profile or a model of a normal web site traffic behavior, and where the detecting step comprises
- detecting an anomaly based on the comparison applied to the profile or the model.
25. A system for modifying a web site, comprising:
- a registration module transmitting a registration message for a web site to a traffic analytics service;
- a linking module linking a resource on the web site to the service;
- a receiver module receiving a comparison of a real-time traffic data of the resource to a second traffic data;
- a modification module modifying the resource in response to the comparison;
- an alert module alerting a user that a modification has been made to the web site after the modification module modifying the web site;
- a notifier module notifying the user the type of modifications made to the web site after the modification module modifying the web site; and
- a sender module sending the user a web site containing a pre-modified version of the web site as well as a modified version of the web site in response to querying the modification module.
26. The system of claim 25 where the registration module comprises receiving at least one limitation on the modifications that can be made to the resource, and the modification module comprises modifying the resource within the limitation in response to the received comparison.
27. The system of claim 25 where the receiver module comprises:
- the receiver module receiving a real-time traffic data for the resource;
- the receiver module receiving a historic traffic data for the resource; and
- a comparison module for comparing the real-time traffic data with the historic traffic data.
28. The system of claim 25 where the modification module comprises:
- a detection module detecting whether an anomaly exists; and
- the modification module modifying the web site in response to the anomaly and the comparison.
29. The system of claim 28 where the detection module comprises:
- a calculation module calculating at least one statistic from the comparison; and
- the detection module detecting an anomaly based on the statistic.
30. The system of claim 28 further comprising: and where the detection module comprises
- a builder module building either a profile or a model of a normal web site traffic behavior,
- the detection module detecting an anomaly based on the comparison applied to the profile or the model.
| 6119167 | September 12, 2000 | Boyle et al. |
| 6247061 | June 12, 2001 | Douceur et al. |
| 6792458 | September 14, 2004 | Muret et al. |
| 7143365 | November 28, 2006 | Gallella |
| 7529835 | May 5, 2009 | Agronow et al. |
| 7559016 | July 7, 2009 | Rakowski et al. |
| 7636677 | December 22, 2009 | McGonigal et al. |
| 7904330 | March 8, 2011 | Uyama et al. |
| 7953791 | May 31, 2011 | Or Sim et al. |
| 8560504 | October 15, 2013 | Parker et al. |
| 20030115333 | June 19, 2003 | Cohen et al. |
| 20040128285 | July 1, 2004 | Green et al. |
| 20050223093 | October 6, 2005 | Hanson et al. |
| 20060104515 | May 18, 2006 | King et al. |
| 20060253345 | November 9, 2006 | Heber |
| 20060265495 | November 23, 2006 | Butler et al. |
| 20060274763 | December 7, 2006 | Error |
| 20070280125 | December 6, 2007 | Sonnier |
| 20080046562 | February 21, 2008 | Butler |
| 20080052343 | February 28, 2008 | Wood |
| 20080065631 | March 13, 2008 | Baeza-Yates et al. |
| 20080126178 | May 29, 2008 | Moore |
| 20080184129 | July 31, 2008 | Cancel et al. |
| 20080248815 | October 9, 2008 | Busch |
| 20080250497 | October 9, 2008 | Mullarkey et al. |
| 20090002333 | January 1, 2009 | Maxwell et al. |
| 20090030859 | January 29, 2009 | Buchs et al. |
| 20090172551 | July 2, 2009 | Kane et al. |
| 20090182614 | July 16, 2009 | Kekre |
| 20090281989 | November 12, 2009 | Shukla et al. |
| 20100318484 | December 16, 2010 | Huberman et al. |
| 20100318976 | December 16, 2010 | Everly et al. |
| 20110029853 | February 3, 2011 | Garrity et al. |
| 20110055250 | March 3, 2011 | Nandy et al. |
| 20110219295 | September 8, 2011 | Adams et al. |
| 20110225287 | September 15, 2011 | Dalal et al. |
| 20120066211 | March 15, 2012 | Gandhi |
| 20120191691 | July 26, 2012 | Hansen |
| 20120278741 | November 1, 2012 | Garrity |
| 20120316902 | December 13, 2012 | Kumar et al. |
| 20120331128 | December 27, 2012 | Seifert et al. |
| 20130013671 | January 10, 2013 | Relan et al. |
| 20130018713 | January 17, 2013 | Kumar et al. |
| WO2012079033 | June 2012 | WO |
- Atterer, Richard, Monika Wnuk, and Albrecht Schmidt. “Knowing the user's every move: user activity tracking for website usability evaluation and implicit interaction.” In Proceedings of the 15th international conference on World Wide Web, pp. 203-212. ACM, 2006.
- “The Web Doesn't Wait—Neither Should You” Charbeat—Real-Time Website Analytics and Uptime Monitoring, retrieved Jul. 19, 2011 from <http://charbeat.com>, 2 pages.
- “SiteCatalyst Product Overview”, Online Analytics | Web Analytics—SiteCatalyst | Online Business Optimization by Omniture, retreived Jul. 19, 2011 from <http://www.omniture.com/en/products/online—analystics/sitecatalyst>, 6 pages.
- “Webtrends: Your Dots, Connect, Analytics 10 Unlocks Ideas for Social, Mobile and Site” Webtrends, Analytics, retrieved Jul. 19, 2011 from <http://www.webtrends.com/Products/Analytics>, 6 pages.
- “Real Time Web Analytics,” Web Analytics In Real Time | Clicky, retrieved Jul. 19, 2011 from <http://getclicky.com>.
- “Features Overview,” Woopra, reteived Jul. 19, 2011 from <http://www.woopra.com/features>, 2 pages.
- Himel, “Building Realtime Insights,” Building Realtime Insights | Facebook, Mar. 15, 2011, retrieved from <https://www.facebook.com/note.php?note—id=10150103900258920> on Jul. 19, 2011. 3 pages.
- “Real-Time Marketing, Simplified,” Interaction Manager Overview, Toovio, retrieved Jul. 19, 2011 from <http://www.toovio.com/Interaction-Manager-Overview>.
- “Real-Time Event Tracking, Measure Actions, Not Page Views.,” Mixpanel | Real-Time Web Analytics, Funnel Analysis, retrieved Jul. 19, 2011 from <http://mixpanel.com>.
- Notice of Allowance on U.S. Appl. No. 13/187,417 dated Apr. 14, 2014.
- Office Action on U.S. Appl. No. 13/187,417 dated Jan. 30, 2014.
- Office Action on U.S. Appl. No. 13/187,418 dated Mar. 24, 2014.
Type: Grant
Filed: Jul 20, 2011
Date of Patent: Nov 4, 2014
Assignee: Google Inc. (Mountain View, CA)
Inventors: Mayur Venktesh Deshpande (Long Beach, CA), Kasem Marifet (Costa Mesa, CA), Jacob Burton Matthews (Chicago, IL), James Lee Wogulis (Laguna Beach, CA), Linus Page Chou (San Francisco, CA)
Primary Examiner: Frank D Mills
Application Number: 13/187,425
International Classification: G06F 17/20 (20060101);
