screen tracking

Good day,

The idea or merging both approaches is in fact "easying" somehow the implementation. Nevertheless, the availability of the screen resolution, along with some other pieces of information, will always be dependent of the users, as they control if javascript is enabled or not on their respective browser. However, the overall concept behind your proposal would alleviate the need to switch back and forth between the "ASP" and "JavaScript" methods, which is exactly the reason why I implemented something similar to what you're suggesting.

With the modifications I did to my scripts, I can now also track the "Server Load Time", "User Load Time" and "User Elapsed Time" for each page being accessed.

The first item, "Server Load Time", is in fact the time required by the server to render the page. I have a call to "Timer()" at the top of the ASP page, and one just before the include of the "track.asp" page. Computing the difference between the two, allows me to estimate roughly how long it took the server to "build" the page. So if for a given page the build time is 200 ms, and suddently it raises and stays around to 500 ms, I would know that something is impacting the server, would it be because it is a busier time or some addition of code impacted the turnaround. As you can see, this piece of information may be used somehow as a debugging/monitoring tool/information.

The two others, "User Load Time" and "User Elapsed Time", are tracked using the same approach as the screen resolution, being javascript.

In the pages I want to track, I added a commonly used javascript, which gets the current system time.

The beauty of the overall process resides in how it is being called, with all modesty. The BODY onload and unload events are triggering 2 different scripts, which were generated by "track.asp" with enough information to get back to the appropriate record on the database and update the related fields.

When the BODY "OnLoad" even is triggered, one of the scripts is invoked, and updates the database asynchronoulsy via a POST and xmlHTTP. So while the user begins the consultation of the page, xmlHTTP is being called with the necessary information to update the record in the background, so the user don't have to wait for it. When the process is invoked asynchronously, you provide xmlHTTP with a callback function, which would then determine if the update indeed took place as expected. You may have an alert message if it failed.

When the BODY "unload" event is triggered, it will then call the second script which in turn will evaluate the time spent on the page by the user, the starting point being the moment at which the "onLoad" event was triggered.

Using another call to xmlHTTP, but this time synchronously, another update takes place with the "User Elapsed Time". The update must be done synchronoulsy in this case, simply because the callback function would not be accessible anymore as the next page would be prepared/loading. A synchronous call doesn't need a callback function either.

So using the "onLoad" and "unLoad" events of the BODY tag, along with xmlHTTP, I'm now able to track information that would normally be only made available by the "javascript" approach as suggested by MT.

Some other elements can be tracked as well, depending of the browser being used. For instance, you may even get a list of the plugins supported by the user's browser, the resolution, the color depth, and so on. All that information is available at the onLoad event, therefore can be computed asynchronously providing the user with a smooth browsing experience.

A minimal amount of information need to be calculated at the "unLoad" event, therefore the time the user will have to wait before the next page is in fact requested from the server, is very minimal, being only few milliseconds.

As I previously mentioned in other posts, I normalized part of the data in the database, which lead me a very smooth implementation.

Actually I'm using the "pl_datetime, pl_ipAddress, pl_SessionID, pl_ScriptNameID and pl_queryStringID" fields to point to the appropriate record.

When passed over to the "update.asp" page (a page I created for that need) via xmlHTTP, I prefix the above variables with "w$", and the ones that will be set/updated will be prefixed with "s$".

When "update.asp" is invoked via xmlHTTP, it parses the variables and construct the UPDATE sql. The "w$" prefixed variables will be in the WHERE/HAVING clause, whereas the "s$" prefixed ones will be used in the build of the SET part of the SQL statement.

I know, it may sounds like a lot of work, but now being able to track some informations that were only available with more costly components, I'm kind of glad I did it and also was a nice challenge to implement.

Initially that xmlHTTP process/approach was used in another project I did, allowing me to populate list boxes with data from a database, using user's filtering specifications, and all of this done without a need to refresh the page. I thought it was a really nice feature, and wanted to implement something usefull like that in MT.

What I did is only one way to do the things. People may come up with some other ideas, which is great. Afterall, this is the main goal of a forum, exchanging point of views and ideas.

Happy tracking.