Finding Sessions

Clusters can making finding where a user was working a clusterf***. Users end up on a node, but they don’t know which node. Heck, we are ahead of the curve to get user name, date, and time. Usually checking all the nodes in the past few days can net you the sessions. Capturing the session ids in the web server logs usually leads to finding an error in the webct logs. Though not always. Digging through the web server logs to find where the user was doing something similar to the appropriate activity consumes days.

Blackboard Vista captures node information for where the action took place. Reports against the tracking data provide more concise, more easily understood, and more quickly compiled. They are fantastic for getting a clear understanding of what steps a user took.

Web server logs contain every hit which includes every page view (well, almost, the gap is another post). Tracking data represents at best 25% of the page views. This problem is perhaps the only reason I favor logs over tracking data. More cryptic data usually means a slower resolution time not faster.

Another issue with tracking is the scope. When profiling student behavior, it is great. The problem is only okay data can be located for instructors while designers and administrators are almost totally under the radar. With the new outer join, what we can get for these oblivious roles has been greatly expanded.

Certainly, I try not to rely too much on a single source of data. Even I sometimes forget to do so.


  1. Most error reports find their way to me after the user has logged out and therefore cannot find out what node they are on.

    Have you found a easy/quick way to find which node a user was on if you have their user name?

  2. The easiest way is a SQL query combining trk_person, trk_action, trk_user_action, trk_page, trk_session, and learning_context. The trk_session.http_session_id has the form of hostname-epochtime-something.

    By getting this information out of tracking first, I have on occasion found that actual time, actual section, etc.

  3. Thanks for that.

    We don’t query against the database apart from the views supplied as part of the PowerSight Kit as I was under the impression that was prohibited by Blackboard…

  4. Blackboard is fully aware we run query against the main application tables part of the main application and not just the PowerSight Kit. They have not told us to stop. By using main application tables you run risks.

    The rpt_tracking.session_id is the same as trk_user_action.trk_session_id who is the key for trk_session table. Using a simple inner join you would only be straying slightly for extremely valuable information in trk_session.http_session_id. šŸ™‚

Leave a Reply

%d bloggers like this: