Please go through my exploring analytics blog post then come to this part
Collecting data :-
The data is represented as a micro-format in the portal page HTML DOM tree and tagged with CSS classes.
An example of such microformat is:-
<span class="asa.portlet.title">My Portlet</span>
Portal will have scripts(aggregators) which reads all such micro-formats and send data to analytics server via 1*1 image before current document unloads.
Step 1 (Creating aggregator) :- Portal provide Active Site Analytics mediator spi using this we can create our aggregator and register it for collecting analytics data.
com.ibm.portal.analytics.SiteAnalyticsMediator. This SiteAnalyticsMediator object defines the following JavaScript functions:
register: function(/*Function*/ listener)
Use this function to register a listener function. You can invoke this listener function by using the portal framework in case of DOM changes that might be relevant for the aggregator. Typically, an aggregator registers one function. The register function returns a string identifier that you can use for unregistering the listener later on. The provided listener function must conform to the following function signature: function (/*DOMNode []?*/ node, /*Function?*/ callback) The optional argument DOMNode [] indicates the areas in the DOM that have changed.
deregister : function(/*String*/ listenerID)
Use this function to unregister a listener function with the identifier that you have obtained during listener registration.
notify : function(/*DOMNode []?*/ node, /*Function?*/ callback)
Use this function to notify all registered listeners about DOM changes. If you know the specific DOM area that has changed, you can pass in the corresponding DOM nodes. This function is typically called by the portal framework to notify the registered aggregators about DOM changes.
Debugging aggregator :-
- Verify that the HTML markup of the portal page contains the micro-formats that the aggregator expects.
- Verify that the tagging method that is used in the themes, skins, and portlets matches the expected behavior of the aggregator.
- If you use the SiteAnalyticsMediator API and your aggregator is not notified about DOM changes as expected, you can enable client side tracing by using the resource environment provider WP CommonComponentConfigService. Set the following two configuration properties:
- To review what occurs in the server side aggregator inclusion code, specify the trace com.ibm.wps.theme.extensions.*=debug
cc.isDebug=true
cc.traceConfig= ["com.ibm.wps.analytics.*"]
After you have done this, save your changes and restart the portal server.
Step 2 :- Copy base javascript from (C:\IBM\WebSphere\PortalServer\doc\js-samples\SampleAggregator) and edit it accordingly . If you are using core-metrics copy CoremetricsAggregator.js.
Step 3 :- Create a page for validating metrics and go to edit page and add a new page parameter as given below
asa_aggregator /wps/mycontenthandler/dav/fs-type1/themes/Portal8.0/js/SampleAggregator.js
Step 4 :- In theme.html add below code exactly above </body>
Step 4 :- In theme.html add below code exactly above </body>
<portal-theme-ext:themeExtension id="com.ibm.portal.theme.plugin.ActiveSiteAnalyticsAggregators">
<portal-theme-ext:themeExtensionLoop>
<portal-theme-ext:themeExtensionItemText />
</portal-theme-ext:themeExtensionLoop>
</portal-theme-ext:themeExtension>
If you are using core-metrics you can show overlay reports please folow product documentation for integration of reports(http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+8+Product+Documentation#action=openDocument&res_title=Displaying_overlay_analytics_reports_wp8&content=pdcontent)
No comments:
Post a Comment