This blog is like a Hollywood sequel, something like Jaws II, where the frightening main character comes back to do more mayhem and mischief. In this case, its the Portal Activity Report that shows the number of logged in users. The Mysteries of the Portal Activity Report explained that the statistics may not show what you had expected, because the report shows unique IDs that visited the portal and not total logons. This may cause you to see fewer logons than you expected, and may cause reports where a weekly report has numbers less than the sum of the daily reports for that week. This week, we take a look at an even more serious issue: some logged in users may not be tracked at all. 
If set to true, the iView is included in the report (if it was accessed, of course). By default, the default framework page iViews -- like content area, TLN, DTN, masthead and so forth -- are set not to be monitored because most customers are not interested in monitoring these iViews. In addition, if you never want to get a report on iView and page hits, you can turn off monitoring of all iViews and pages by setting a service property in the service configuration iView, as shown below: 
Logons are NOT Monitored
You can get a report that shows how many users logged on during a specific period (we already know that this means unique users). But you should know that logons are not monitored. Instead, users are considered to have logged on only when they visit an iView or page that is being monitored for hits. The actual logon is not monitored. And this means that if a user does not navigate to a montitored iView or page, the user is not listed as having logged on.Monitoring iViews and Pages
To explain, let's first talk about the report that shows hits for specific content, that is, for specific iViews and pages. There is a report that shows the number of hits to each iView or page. But it only monitors iViews and pages that are set to be monitored. This is done by setting the Monitor Hits property, as shown below: If set to true, the iView is included in the report (if it was accessed, of course). By default, the default framework page iViews -- like content area, TLN, DTN, masthead and so forth -- are set not to be monitored because most customers are not interested in monitoring these iViews. In addition, if you never want to get a report on iView and page hits, you can turn off monitoring of all iViews and pages by setting a service property in the service configuration iView, as shown below: Affect on Logged on Users Report
The setting for monitoring iViews and pages are designed to filter the content that you want in the hits report, but it also affects the logged on users report. As we mentioned, logged on users are not tracked when logging in (as you might expect) but when navigating to an iView or page that was monitored. During that request, a record is added to the database indicating the user logged in (if a record does not already exist for the time period -- remember, unique IDs are tracked, not actual logons). So, if a user logs on, and then navigates only to pages that are not monitored, the user never is shown in the logged on user report. What's more, some customers are not interested in monitoring what content was seen, just how many logons there were. So if you configure the set activity report service to not monitor any iViews and pages, then you also wont monitor logons.The Good News
Sorry for confusion. Here's the good news: First, you can change the settings to track what you want. If you want to track logons, you can set the logon iView to be tracked or some other home page iView, and then all users will be tracked. Second, improvements are being to provide a greater amount of information on users and their activity, including performance of iViews, navigation patterns and the like. This will be coming soon.
10 Comments
