Focal Pointers! We are in the process of re-evaluating how we track application usage. In our old application interface, users would select hierarchy values (and sometimes date ranges) and we would pass those values to a database, every time a report was run.

In consideration of 21st century upgrade, we realize that every report run is not a good method to track usage- in clicking to the desired level of detail, multiple reports may run.

Certainly, we can track breadcrumbs prior to a download, but I wanted to get opinions of how much detail is too much- all clicks, some clicks, all reports, download only: where do folks draw the line. Does anyone save the entire QUERY_STRING from the Header Variable?

All clicks seems too much; simple page views seems too little; where's the Mama Bear porridge for portal metrics?

And yes, I am aware of Resource Analyzer; I am just not sure if that is the level of detail that tells me if a portal-based application is successful.

Thoughts appreciated.

This message has been edited. Last edited by: FP Mod Chuck,

Personally (and it's MHO) I would say that there no good or bad answer. All depend on your request and each company will have its own needs.

Some wants to know every single DB request including all the drill down, some only the first one (skip the drill down), some care only about the page load and don't mind about the ten reports loaded on the page...

EUM tracks both server and client activity including what's happening on the Portal.

https://www.informationbuilder...prise_usage_mgmt.pdf

What are the questions that the business is trying to answer?

The basic question is, as Don pointed out: "What are the questions that the business is trying to answer?"

We're considering EUM. But, that requires a license ($), right?

I created a 'Home Grown' User Tracking App that's included where ever it's needed, like only one reporting in each portal page/tab and records the specified results in a foc file. It works fine, quick, easy, and easy to use for reporting.

  PS: Hi Don.