May 19, 2012

How to track CQ component clicks in SiteCatalyst

When SiteCatalyst’s tracking is enabled on a site, the overall site traffic and page-to-page traffic tracking is pretty much given and administrators usually do not have to do anything. But one of the requirements that most companies desire is the component tracking capability – to be able to tell which component on a page the users are coming from. Here’s a typical scenario:

  • A featured article is displayed inside a Slideshow or teaser type component on a page, e.g.
  • The same featured article is displayed inside another component (e.g. Spotlight component) on the same page –


  • To be able to track traffic at component level.

In order to do this, two SiteCatalyst variables will need to be introduced:

  • A variable on tracking what components are “clicked from”. In this example I named the variable “Clicked From Component”.
  • A variable on tracking what pages the components lead to, or “clicked to”. In this example I named the variable “Clicked To Page”.

And it is critical to set up a correlation between these two variables:

On to CQ:

On the CQ side, components will need to be customized to pass the variables onto the “clicked to” page so traffic can be tracked. For instance, links can be modified to have additional parameters like the following:


And on pages that should be tracked, the following code can be inserted to surface the variables inside CQ’s clickstreamcloud:

if (request.getParameter("trackFrom") != null) {
        String trackFromComponent = (String) request.getParameter("trackFrom");
        <span record="'trackComponent',{'clickedFrom':'<%=trackFromComponent%>','clickedTo':'<%=request.getRequestURL()%>'}"></span>


Then these parameters will be surfaced inside CQ’s clickstreamcloud:

To map these events to SiteCatalyst variables, (after traffic variables setup in SiteCatalyst), simply Edit the clickstreamcloud and map the following events to variables:

  • clickedFrom – “Clicked From Component”
  • clickedTo – “Clicked To Page”



Once all the above is done, you may click around and start viewing the “Clicked From Component” report in SiteCatalyst. And to view how components are “clicked to” certain pages, the correlation report surface that very nicely.

Clicked From Component Report


Correlation Report

2:21 PM Permalink

How to downsize OOTB DAM’s web rendition

By default, upon image upload to CQ’s Digital Asset Management, a “DAM Update Asset” workflow would be triggered and one of the many processes inside the workflow is to generate a web rendition of the uploaded image. And the default setting of CQ’s Image API is to always render the web-enabled version of the uploaded image. This combination helps to limit the size and the quality of the image displayed thus reducing the page load time.

The OOTB setting for the web-enabled image dimensions is set to 1280 pixels by 1280 pixels. And the image quality is set to reduce to 90%. To change this setting, browse to CQ’s workflow console and select the “DAM Update Asset” workflow under the Models tab:

Inside the workflow model, select the Web enabled rendition step:

Then adjust the settings accordingly. In my example below, I have set the maximum dimension to be 640pixel by 640pixel. I have also reduced the quality of the images to 80%:


Preliminary testing shows that file sizes of this setting (in comparison with the OOTB 1280px by 1280px; 90% quality setting) is reduced by a third, while difference in image quality is minimal. YMMV, please adjust your settings accordingly.

12:36 PM Permalink

How to enable and test CQ’s permission sensitive caching

In this blog post I would like to extend on the permission sensitive caching knowledge base item documented at:

One thing to note is that the auth_checker configuration should be placed under the site configuration (usually under the farm entry). Here’s an example:

# each farm configures a set off (loadbalanced) renders
  # first farm entry (label is not important, just for your convenience)
    # Authorization checker: before a page in the cache is delivered, a HEAD
    # request is sent to the URL specified in 'url' with the query string
    # '?uri='. If the response status is 200 (OK), the page is returned
    # from the cache. Otherwise, the request is forwarded to the render and
    # its response returned.
      # request is sent to this URL with '?uri=' appended
      /url "/bin/permissioncheck.html"
      # only the requested pages matching the filter section below are checked,
      # all other pages get delivered unchecked
          /glob "*"
          /type "deny"
          /glob "*.html"
          /type "allow"
      # any header line returned from the auth_checker's HEAD request matching
      # the section below will be returned as well
          /glob "*"
          /type "deny"
          /glob "Set-Cookie:*"
          /type "allow"
      # client headers which should be passed through to the render instances
      # (feature supported since dispatcher build


To test the PermissionHeadServlet created for permission sensitive caching delivery purposes, the curl command would be your friend. Here are some examples of the commands to retrieve the authentication status on a “locked-down” item in DAM:

[Without Proper Authentication]:

$ curl --head http://_pubserver_:_port_/content/dam/testsite/documents/sensitive_doc.pdf

And here’s the result:

HTTP/1.1 403 Forbidden
Connection: Close
Server: Day-Servlet-Engine/4.1.17
Content-Type: text/plain;charset=UTF-8
Date: Sat, 19 May 2012 18:17:36 GMT
Transfer-Encoding: chunked
X-Reason: Authentication Failed
Set-Cookie: JSESSIONID=c6a8de36-be69-4e9d-8706-df4bd79c3062; Path=/; HttpOnly

[With Proper username/password]:

$ curl --head http://_pubserver_:_port_/content/dam/testsite/documents/sensitive_doc.pdf --user admin:admin

And here’s the result:

HTTP/1.1 200 OK
Connection: Keep-Alive
Server: Day-Servlet-Engine/4.1.17
Content-Type: application/pdf
Content-Length: 758951
Date: Sat, 19 May 2012 18:25:07 GMT
Last-Modified: Wed, 07 Mar 2012 00:14:39 GMT
11:30 AM Permalink