3 Replies Latest reply: May 28, 2012 10:39 AM by Alexander Fulton RSS

Plugin: Unique visitors on any custom report via plugin to v10.x tag

Alexander Fulton Newbie

Overview

One of the cool new features with the Analytics v10.2 tag is the integration of 'plugins' easily, without requiring any modification of the base Webtrends tag at all.

 

Merely take the html component of the tag that would have been deployed to any and all pages, and add a single line to install your plugin!

 

For this plugin, a new .JS file is delivered. The client simply needs to copy this .JS file to their server (likely, in the same directory as their base Webtrends.js file), and then place in the 'visitorParams' optional variable the semicolon-delimited list of query parameters that unique visitors should be tracked to (example of installing this in red):

 

<!-- START OF SmartSource Data Collector TAG v10.2.0 -->

<script>

window.webtrendsAsyncInit = function () {

var dcs = new Webtrends.dcs().init({

dcsid: "dcsjdm2v3wz5bdmnqycxud49h_2c6i"

, domain: "statse.webtrendslive.com"

, timezone: 0

, download: true

, downloadtypes: "xls,doc,pdf,txt,csv,zip,docx,xlsx,rar,gzip"

, plugins: {

VisitorTrack: { src: "/scriptsA10/visitorTrack.js", visitorParams: "z_color;z_shape" }

}

}).track();

};

(function () {

var s = document.createElement("script"); s.async = true; s.src = "/scriptsA10/webtrends.js";

var s2 = document.getElementsByTagName("script")[0]; s2.parentNode.insertBefore(s, s2);

} ());

</script>

<noscript><img alt="dcsimg" id="dcsimg" width="1" height="1" src="//statse.webtrendslive.com/dcsjdm2v3wz5bdmnqycxud49h_2c6i/njs.gif?dcsuri=/nojavascript&amp;WT.js=No&amp;WT.tv=10.2.0&amp;dcssip=www.pdxfultona01.com"/></noscript>

<!-- END OF SmartSource Data Collector TAG v10.2.0 -->

Pretty simple!

 

Once that is done, reporting for unique visitors can be configured around this. For each query parameter identified, we will track unique visitors by setting a cookie with that parameter name.

 

IE., for the above implementation, tracking "z_color" and "z_shape", we will see the cookies with a name of 'z_color' and 'z_shape' that store all the values for these parameters that has been seen by the visitor, as well as the date which that particular value was seen on. (The customer does not need to configure anything here, this is just informational)

 

Within Webtrends reporting, then, we will set a number of new query parameters based on the requested 'track visitors' set. These will take the format of the requested value, appended by a value to identify the period this visitor should be counted towards, as such:

 

SuffixExample ValueMeaning
_nWT.z_color_n'New' visitor from all time
_dWT.z_shape_dVisitor first view of this value on this day
_wWT.si_n_wVisitor first view of this value on this week
_mWT.oss_mVisitor first view of this value on this month
_qWT.z_color_qVisitor first view of this value on this quarter
_yWT.z_shape_yVisitor first view of this value on this year

 

We can then configure measures in Webtrends reports, using 'all hits' counting, based on the source query parameter. IE., a count of "WT.z_color_n" as a measure for a dimension of "WT.z_color" will yield, for each value of that dimension, the count of unique new visitors to that value in the requested report period.

 

Configuration and Example

As a more complete example of reporting configuration:

 

Measure: "Daily Visitors (color)"

Value to Base On: Query Parameter

Parameter Name: WT.z_color_d

When to Measure: All hits

Sum across the visit: No

 

Measure: "Weekly Visitors (color)"

Value to Base On: Query Parameter

Parameter Name: WT.z_color_w

When to Measure: All hits

Sum across the visit: No

 

Measure: "Monthly Visitors (color)"

Value to Base On: Query Parameter

Parameter Name: WT.z_color_m

When to Measure: All hits

Sum across the visit: No

 

Measure: "Yearly Visitors (color)"

Value to Base On: Query Parameter

Parameter Name: WT.z_color_y

When to Measure: All hits

Sum across the visit: No

 

Measure: "Colors"

Value to Base On: Query Parameter

Parameter Name: WT.z_color

When to Collect Data: All Hits

 

The resulting report might appear as:

ColorDaily VisitorsWeekly VisitorsMonthly VisitorsYearly Visitors
Red320200905
Orange210150859
Yellow1901407515
Green1651526612
Blue13512410050
Indigo1251108045
Violet119504038
Black118454035
Grey110353025
White501085

 

Anyway, that's all there is to it!

  1. Implement the client with the base Webtrends 10 tag
  2. Copy the 'visitorTrack.js' into the client's scripts source directory, alongside the Webtrends 10 tag
  3. On the HTML component that includes the tag, placed on each page, simply include a line to install the visitorTrack.js plugin on pages you want to track visitors on, with the query parameters identified that you wish to track
  4. Configure the 'visitor'-related measures that are variants of the query parameter you are tracking unique visitors to, and build them into reports!

Caveats

As with any new feature of this complexity, it comes with some caveats that are easy to work with, but must be considered:

  • This capability works by storing data within a cookie for each parameter, specifically, unique time viewed for each query parameter value. A cookie can thus get pretty big:
    Name: z_color
    Content: Red=20120415:Green=20120326:Blue=20120326:Yellow=20120326:Orange=20120326
    Host: pdxfultona01
    Path: /testa10/
    Sent For: Any type of connection
    Expire: Tuesday, March 26, 2013 4:28:54 PM
    ...this should be monitored, as there are obviously constraints for cookie size. The minimum recommended support for cookies as outlined in RFC2109, section 6.3, suggests (noting that this is just a 'minimum'...most browsers do support more, but we cannot assume that):
    • 300 total cookies
    • 20 cookies per host/domain (this will be the biggest immediate challenge, in that the domain is likely already using 3 to 5 cookies just on its own and alongside Webtrends standard cookies)
    • 4kb per cookie (assuming 20 bytes per value/datestamp pairing, that is about a cardinality of 200 different values per query parameter, max)
  • The design of the plugin .JS presumes that each query parameter will have no more than one value per page. That is, query parameters with semicolon-delimited lists of values will not be handled. This was an intentional design decision, owing to the above constraints around cookie size and resulting data cardinality. If you are, on every page, passing query parameters with multiple values and trying to track visitors to these...you are using this incorrectly. Target no more than 100 different potential values, for no more then 15 different query parameters, passing no more than one value per page for any given parameter.
  • Obviously, the resulting report configuration will call for some interpretation of the data. Viewing a week of time in the calendar and reading the 'daily visitors' will not "de-dupe" the visitors by day...instead, you will have the visitors for each day to that parameter, totalled up for the length of the week. If you want the "de-duped" visitors per value for the week, then when looking at the week in your calendar, you must read the 'weekly visitors', not the 'daily visitors'. Standard Analytics reporting simplifies this somewhat, although the same logic is happening behind the scenes, with the existence of an aliased "dynamic visitors" report measure that is actually just presenting the data from the appropriate 'period visitors' for the selected report period. Obviously, that is not possible with these custom measures.
  • The custom plugin presumes that the variables you are identifying are in the "WT" object, that is, are labelled within the site meta data as "WT.something". "DCS." and "DCSExt." are not supported from the meta data at this time.
  • The only multiTrack call tested was using the new multiTrack implementation, with values passed as a JSON object, rather than the legacy method. IE., the new method would have a multiTrack function as so:

Webtrends.multiTrack({ element: this, args: { 'WT.ti': 'Submit Button', 'WT.dl': 1, 'WT.z_color': colorVal, 'WT.z_shape': shapeVal} });

  • Plugin: Unique visitors on any custom report via plugin v10.x tag
    Paul Lawbaugh Novice

    Super useful.  This is great!

  • Plugin: Unique visitors on any custom report via plugin to v10.x tag
    rob.1.ashton@uk.zurich.com Newbie

    Great introduction.

     

    Would this work for things like unique visitors to pages?

    Could we use tag js v10.2  (as in your article) with Analytics v9 on premises?

     

    Thanks.

    • Plugin: Unique visitors on any custom report via plugin to v10.x tag
      Alexander Fulton Newbie

      rob.1.ashton@uk.zurich.com wrote:

       

      Would this work for things like unique visitors to pages?

       

      The implementation method would *theoretically* allow counting unique visitors to a page (tracked as unique visitors to WT.ti parameter values), however in practice this probably won't work.

       

      As noted above, what we are doing with the plugin is storing each value for the parameter in a cookie, along with the date it was last observed in...

       

      Red=20120415:Green=20120326:Blue=20120326:Yellow=20120326

       

      The challenge with using something like a 'page' is that the value tends to be a LOT larger a string than just values like 'Red' or 'Green' or 'Blue', etc...and there are limits as to how long any given cookie can be (and how many bytes all cookies on a domain can be) in many browsers.  In fact, the limit TENDS to be pretty low for the total possible length of the above strings, so the plugin is designed to only allow up to 1024 characters per query parameter tracked - that would include all potential values, along with the matching date information.  The cookie gets updated with FIFO logic - newest data pushing the oldest data out of the cookie.

       

      Now, that said, if the 'pages' in question were not using possibly-several-hundred-character-long WT.ti values, but maybe just a 'page ID' that is a short numeric string...that may well actually work okay.

       

      And, of course, as this is all .JS, that 1024 character limit I included could simply be increased or removed...although you would then risk compatibility issues with older browsers that could have an unpredictable impact on reports.

       

      rob.1.ashton@uk.zurich.com wrote:

       

      Could we use tag js v10.2  (as in your article) with Analytics v9 on premises?

       



      No, the code as provided requires the v10 plugin interface, and the v10 tag does not work with Analytics v9 on premises (there were some changes made in the SDC server code between v9 and v10 that prevent compatibility between the two tags).

       

      The actual logic the plugin is doing, of course, is pretty straightforward (setting client-side cookies, comparing dates and timestamps, etc), so it could certainly be re-factored into a v9 tag extension, but I haven't done that work, here - the code above is v10, only.