YaleInfo Web Analytics

YaleInfo Web Analytics Options

Proposed Analytics Requirements

Functional Perspective:

* We can track  by content group (staff/faculty/student/etc) and tab which portlets are displayed on a tab, and which portlets either have a link or button clicked.  Note that if links or forms are dynamically created through javascript after the portal page is rendered, special code may need to be added to bind the dynamically created links or forms to a tracking event.

**Not 100% sure what this means, but if it means which content group clicked an outgoing link from which tab and portlet, this can be tracked.

***  We are not currently gathering these statistics, and they are not yet supported by the Stats Aggregator.  However, we can begin to collect these statistics by adding the following entries to the uportal-impl/src/main/resources/properties/context/statsContext.xml. 

 
Technical Perspective:

 * We can capture page views (and therefore unique users) by content group (staff, faculty, student, guest).  By excluding guest visits, we can determine the number of logged in users.

** Stats Aggregator captures login frequency, unique logins, and total logins by time period and portal group.

UPortal StatsAggregator

The UPortal StatsAggregator was developed for the University of Wisconsin to aggregate and analyze usage statistics that can be tracked in by portal statistics.  See http://www.ja-sig.org/wiki/display/UPC/Database Event Logger for details of the statistics that are gathered in the database.   The aggregator summarizes statistics into a separate database schema, and purges statistics from the UPortal STATS_EVENT, STATS_SESSION, and STATS_SESSION_GROUPS tables once aggregation is complete. Currently YaleInfo is gathering statistics only for CHANNEL_RENDERED, PORTLET_ACTION, LOGIN, PAGE_RENDER_TIME, and LOGOUT events.  Edit uportal-impl/src/main/resources/properties/contexts/statsContext.xml to add other events described on the JA-Sig wiki page referenced above.

The StatsAggregator can be started and stopped by a shell script.  The StatsAggregator runs a Quartz job that runs on a user designated schedule and performs both the aggregation and the purge activities.   It requires that data source parameters (including id and password) for the UPortal and UPortal Statistics databases are entered into a properties file.  It can be run from any place so long as it can access the databases.  The system requires delete access on the UPortal stats tables as well as read access to other tables in the database.  It requires full access to the tables in the aggregation database.

The StatsAggregator specifically supports the following UPortal events:

    CHANNEL_RENDERED
    PAGE_RENDER_TIME
    SESSION_CREATED
    SESSION_DESTROYED
    PORTLET_ACTION
    CHANNEL_TARGETED

for aggregation intervals of: 

     MINUTE
    FIVE_MINUTE
    HOUR
    DAY
    WEEK
    MONTH
    CALENDAR_QUARTER
    ACADEMIC_TERM
    YEAR

 Existing Event Aggregators:
    TabAggregateWriter & TabAggregateDaoImpl - key(date, time, tab name, interval, portal group)
        - Portal tab request count
        - Portal tab total render time
        - Portal tab max render time

    PortletAggregateWriter & PortletAggregateDaoImpl - key(date, time, fname, interval, portal group)
        - Portlet render count
        - Portlet render total time
        - Portlet render max time
        - Portlet action count
        - Portlet action total  time
        - Portlet action max time
        - Portlet targeted count
        - Portlet rendered from cache count (cached renders do not count towards total or max render times)
        
    ConcurrentUserAggregateWriter & ConcurrentUsersDaoImpl - key(date, time, interval, portal group)
        - Concurrent users (counted as having a portal event during that interval)
        
    LoginFrequencyAggregateWriter & LoginFrequencyDaoImpl - key(date, time, interval, portal group)
        - Count of users that logged in once
        - Twice
        - 3 to 5 times
        - 6 to 10 times
        - 11 to 25 times
        - 26 or more times
        
    LoginsAggregateWriter & LoginAggregationsDaoImpl - key(date, time, interval, portal group)
        - Unique Logins
        - Total Logins

Benefits

1.  If we plan to continue gathering statistics in the UPortal database, we need to implement a purge strategy.  The StatsAggregator includes a purge mechanism in addition to a mechanism to aggregate the gathered statistics.

Potential Issues

1. The StatsAggregator needs custom reports to be written using a tool such as Hyperion Brio.  It comes with a set of sample queries, but we would need to determine what data might be of interest to our stakeholders.
2. The StatsAggregator requires that all dates to be analyzed are inserted into the  Date_Dimension_T.  I think this is required because of the system ability to map dates to specific academic terms. It seems to me that we should be able to improve on this design to automatically include new dates.
3. We typically do not want to store data source parameters in properties files.  We would prefer to access them through JNDI.
4. We might want a mechanism to start and stop the StatsAggregator from the portal.  This would involve adding a servlet interface.

Google Analytics Strategy

 Framework Modifications

•  Javascript Libraries:
  • Consider using jquery.google-analytics.js for interaction with Google Analytics.  This is not completely necessary, but it may simplify some of the coding.
  • In order to prevent an automatic page refresh by the portal, which occurs with some portlet interactions, consider using jquery.cookies.js to update a non-persistent cookie when a tab is clicked.  The cookie will contain the tab name and content group.  Note that it could also contain the netid.  This cookie will can be tested when the page refreshes to see if the user has changed tabs.  If the cookie content has not changed, then do not record a new page view with GA.
• Modifications to expose the contentGroup to universality.xsl. 
  • Create edu.yale.portal.layout.dlm.YaleThemeParamInjector class to inject the content group as a parameter into the transformer.  Note that if it is desirable to expose additional information, this logic can be added here.
  • Add YaleThemeParamInjector declaration into uportal-impl/src/main/resources/properties/contexts/layoutContext.xml
• Modifications to existing xsl:
  • universality.xsl - add javascrip libraries, contentGroup (available through the YaleThemeParamInjector described above), and up.jQuery.trackPage call
  • preferences.xsl - add analytics template with javascript to control calls to GA.
  • page.xsl - include call to analytics template (on preferences.xsl)

Portlet Modifications

• Ajax Modifications
  • If we want to capture clicks on dynamically generated links or forms, we will need to modify the javascript to bind them dynamically to tracking events.  One example is the Yale Events portlet detail event information.  The event link will not be automatically bound to a tracking event unless modifications are made in the javascript, since all automatic GA event binding will occur at the time the portal page renders.  Note that the jquery live functionality might be used to solve this problem, but so far, I have not been able to get this to work.
    

Proposed events to write to GA

• Pageview:
  • Portlet Page Rendered by content group and tab: /[contentGroup]/YaleInfo/[active tab name]
  • Outgoing Link Clicked by content group and portlet: /[contentGroup]/[portlet name]/outgoing/Link text
  • Outgoing link clicked from Magic Y: same as portlet link clicked with portlet name = MagicY
  • Outgoing link clicked from portal page bar links: sams as portlet link clicked with portlet name =  portalPageBarLinks
• Event Tracking:
  • Portlets rendered by content group and tab: Category: contentGroup; Label: Portlet name; Event: loadPortlet
  • Links clicked by content group and portlet (includes internal links), and can be used to track portlet usage: Category: contentGroup; Label: Portlet name; Event: Click; Action: Submit
  • Forms submitted by content group and portlet to be used to track portlet usage: Category: contentGroup; Label: Portlet name; Event: Submit; Action: Submit
• Page refreshes due to Portlet actions:  Use cookie to prevent recording page view each time the page refreshes due to an action in a portlet (such as the Yale events portlet).