at my client we are implementing a Webcenter Framework Portal. We are serving 2 departments of the client with a single portal deployment and use customizations to apply a number of fairly small variations between the pages for the departments.
The customer wants to use Webcenter analytics to get an insight of the use of the portal. They want analytics data for both departments to be split and prevent users from one department seeing analytics data of the other.
Since we have users that can use both flavors of the portal, it is not possible to use a user property to determine the department that the user was getting a page for.
Does anybody know of a way to distinguish between customizations in the analytics data (and how to use that in the OOTB analytics taskflows)?
We would like to prevent from having to deploy the portal as different applications for the departments. Clearly this would fix our problem, since this results in two applications, on which analytics data can be split, but it would also result in a lot of undesirable extra work.
Correct me if I am going down the wrong path but - Can't you use the URL to determine the application name in the sendPageViewEvent method? Then when adding the analytics taskflow use an EL to evaluate the applicationName TF parameter?
application name is not one of the parameters for the AnalyticsUtil methods. It is determined based one the Webcenter Application name of the deployment.
Also, I don't realy like the idea of having to set this distinction in the method calls that register the event. For pageviews, this is no problem, since I have to add that manually to my application anyway, but it would mean I have to implement the registration of all OOTB events (like login, document download etc) manually as well.
So far, I have come up with a workaround to split the data:
I register a custom event when the login page is viewed and when the user is logged in (you need to be authenticated for all pages, except the loginpage), where I register the department with the sessionid.
Then, on a batch basis, I schedule a database job, the moves all FACTs to the "dummy" application that belongs to the selected department (based on the department registered/sessionid combination registered by the custom event).
I am now implementing this to test this workaround, but I am hoping for a cleaner way to fix this, without having to manipulate the analytics data directly in the database.