Oops. I know this thread is dead, but I wanted to correct myself in that
unique users should be gathered by unique username not by unique IP
(most likely).
Gary Weaver wrote:
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
