|
![]() ![]() ![]()
|
|
Design The architecture of the wane system was designed with modularity in mind -- I wanted w.a.n.e. to be able to integrate into any site, regardless of what technologies it was using. To this end, w.a.n.e. can be run on its own server, and all that is required of the site wishing to use it is that a small amount of HTML code must be appended to all the pages. I will call the server where w.a.n.e is installed the traffic server, and the server where the rest of the content is stored will be called the content server. When a browser makes a request for a page on the content server, the server sends the page, along with the snippet of HTML appended at the bottom. The small snippet of HTML is essentially an image tag, with the URL of the page currently being viewed embedded in the When the traffic server receives a request, it parses the request to extract the data it needs (like the IP address of the user, the name of the user's browser, etc.). It uses the HTTP headers that are exchanged in the request to enforce session tracking and cache control of the image. This prevents errors that result from proxy servers, dynamic IP addresses, and browser caching. Once all this has been completed, the traffic server stores the resulting data in the database, and sends a transparent GIF file back to the user. To the user of the web site, it appears as if nothing has happened. Once data is stored, an administrator can use a web interface to run analyses on the data. An example of this can be seen in the demo, available here. The main advantage of this architecture is that the overhead involved in collecting and analyzing traffic data is completely offloaded to the traffic server. The content server can continue to serve pages as it does with or without tracking, and the user will not notice any slowdown in the site. |
|