Eric,
I noticed that 2nd gen stats collection included login stats.
You might consider adding "IP unique" login stats to the general logging
stats.
It would be also cool to collect concurrent # session statistics, but
with the research I've done on that, I'm not sure whether there is a
consistent way of doing that.
However, you might consider not integrating any ability to send the
stats automatically, since there could be privacy concerns about that
functionality being there, even if it could be configured not to send
them. I think it would be better for the portal admin or a functional
owner of the portal to review those stats before approving them to be
sent (each time). One way to do this (maybe not the best) would be for
each the portal itself or JASIG send emails to that person to let them
review and send only the stats they want to. I know that it is probably
much easier to just automate sending of stats, but odds are more people
would feel comfortable with sending those stats if they could look at
them first and maybe choose which to send.
In the end though, I don't think that gathering stats at JASIG will be
of much help. I could see Unicon possibly wanting to focus on some data
like "they've had a significant drop of logins- maybe we should see if
they need assistance", but in the end if something like that happens,
the institution using uPortal probably already knows about it and might
get annoyed that it is being used for the purpose of vetting potential
need for assistance. And JASIG itself wouldn't seem to benefit from
these stats other than possibly being able to advertise something like
"the highest # logins/day we are aware of in the wild is ~8000" to try
to increase adoption. And there could be a number of dev/test instances
registered using the same config as production, so load testing and lack
of use of those could significantly affect numbers. Finally people that
are checking into using uPortal are probably more interested in load
testing results and information to help them determine system
requirements and suggested architecture for a particular theoretical #
users than anything else.
While on the topic of stats collection in uPortal (not that it has to do
with JASIG stats collection):
* Internally we track a lot of login stats based on different attributes
of users: for a given time period we report total logins and unique
logins, " " " " " by career, " " " " " by grad year, daily stats of
total logins and unique logins for career and grad year (Matt Young
wrote our code to gather additional data and do all of the previous
reports btw), and then total and unique logins broken down by month, and
total logins and unique logins for career and grad year broken down by
month (I added those last 2 later). If those types of reports (tapping
into user data fed in via the SSO or LDAP) could be part of uPortal
itself, that would be cool for some portal admins, I'd expect.
* In terms of stats collection, our customer would really like for the
portal to collect stats on usage of portlets including number of times
portlet viewed (per day, etc.) and what the user clicked on, etc.
Unfortunately this is much harder to track generically without changes
required to each portlet to store that data. If there was a way to solve
this, that would be excellent.
Hope this helps.
Thanks,
Gary
Eric Dalquist wrote:
The last uPortal steering committee meeting had some very good
feedback from several sources about Jasig needing to do a better job
keeping track of portal deployments. To that end there have been some
discussions on the IRC channel that I thought I'd post about here.
There is a wiki page describing the plan and design:
http://www.ja-sig.org/wiki/display/UPC/Automated+Portal+Registration
The first step is something that we're going to try and get into the
3.1.0 release. It will be a portlet designated for the admin view that
provides a simple form for the administrator to fill out some
information about their install and some checkboxes about
automatically discovered data. The admin can then submit this
information to a small webapp that will reside on www.ja-sig.org.
Handling the data would then be up to the steering committee to deal
with. Including this at the last minute is a tough call but as the new
code will be in no way critical for uPortal to run the risk versus the
reward is worth it.
We would very much like feedback on this though. Please review the
wiki page first and any comments, questions or suggestions are more
than welcome.
-Eric
--
Gary Weaver
Application and Database Services
Office of Information Technology
Duke University
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
