Back from Long Summer Break

August 27th, 2009

Hello all

I’m back from my unusually long summer break, hope to be able to write new articles soon!! :)

VN:F [1.3.2_665]
Rating: 0.0/5 (0 votes cast)

24th of June 09: Web Analytics Wednesday

May 19th, 2009

For our swiss Web Analysts, Marketers and anyone interested in this subject, the WAA’s (Web Analytics Association’s) Web Analytics Wednesday will be held on 24th of June 09 in Lausanne Switzerland.

Signup here: Web Analytics Wednesday Lausanne, 24th of June 09

Would be glad to meet you there!

VN:F [1.3.2_665]
Rating: 0.0/5 (0 votes cast)

Rating System on Web Analytics Cookbook

May 18th, 2009

Dear all

I just added a rating system to my blog, in order to obtain a vague idea if you like or not my posts… I would appreciate any feedback!

Thanks :)

VN:F [1.3.2_665]
Rating: 0.0/5 (0 votes cast)

Maximum URL Length Web Analytics

April 27th, 2009

I received an organic search visit with the search phrase “maximum length of a URL web analytics”. So the answer: To my knowledge, there is no limitation in URL lengths due to analytics softwares. However, maximum URL length depends on browsers.

Currently, IE 7 is limited to 2048 characters in terms of URL that can be used for a request. In other terms, any web analytics software relying on client side tagging is limited by this same maximal URL length, and the server call to collect data must not be longer than 2048 characters. The server call inlcudes the URL of the tagged page PLUS any other information that is collected by the tag, e.g. referrer, client configuration, visitor id… So the limit of the tagged page’s original URL is much lower than the actual maximum URL length allowed.

Most other web browsers have some limits as well, but those are quite high and shouldn’t impact ability to collect data (more information here: http://www.boutell.com/newfaq/misc/urllength.html).

In the field of mobile browsing, URL limitation can be much lower. Many handsets still don’t support URLs longer than 128, 256 or 512 characters, in particular WAP devices (as opposed to devices carrying a full blown HTTP browser).

VN:F [1.3.2_665]
Rating: 4.0/5 (2 votes cast)

Maximum Length of Configuration Values in WebTrends

April 23rd, 2009

In my modest experience configuring WebTrends custom reports, I happened to stumble upon some nifty idea to create a new report, but then, once half way through configuration, some undocumented and unexpected limitation of the length of a configuration value suddenly annihilated all my hopes…

Therefore, I decided to start this post, where I will collect and document all limitations I have or will yet discover.

Field Name Where Limit
Regular Expression Edit Dimension > Based On > Advanced 100
Identification String Parent/Child Profile > Identification Strings 50
Child Profile Description Child Profile > General 256
Report Title Child Profile > Report 256
Match Pattern Child Profile > General 256
VN:F [1.3.2_665]
Rating: 0.0/5 (0 votes cast)

Custom Report on Traffic Origin

April 21st, 2009

I just completed a report which might interest many marketers but isn’t available by default in WebTrends. It is a report showing distribution of traffic origin among Organic, Paid Search and Paid Referral (Marketing Campaigns):

trafficorigin

Here is how to create it:

  1. Create a dimension called traffic origin
  2. Base it on Entry request
  3. Click Advanced
  4. Override Default String to “Organic”
  5. Apply regular expression “.*(WT\.mc_id|WT\.srch)=.*”
  6. Translate with a translation file containing
    SOURCE,LABEL
    WT.srch,Paid Search
    WT.mc_id,Paid Referrer
  7. Save
  8. Create a custom report
  9. Use the dimension you defined beforehand
  10. Add any visit based measure (Visits, Pages/Visit, Orders, Product Views, etc.)
  11. That’s it :)

Remarks:

  1. The regular expression extracts either “WT.mc_id” (if present) or “WT.srch” (if present) or <empty string> (which then is set to “Organic” by the overridden Default String.
  2. The Lookup Table then translates “WT.srch” to “Paid Search” and “WT.mc_id” to “Paid Referral”.
  3. As the custom dimension is itself based on a standard visit based dimension, all visit based measures (Visit Duration, Visit Page Views, etc.) are available in the Measures tab.
  4. This assumes that incoming links (first hit in a visit) never contain WT.srch and WT.mc_id paremeters at the same time.
  5. You shouldn’t, unless you know what you are doing, use visitor based measures with this report.

Any remarks or questions are welcome! :)

VN:F [1.3.2_665]
Rating: 5.0/5 (4 votes cast)

Parent/Child Profiles - Basics

April 3rd, 2009

Finally, the first post out of this series. I decided to start off with some basics. Basics about what Parent/Child profiles are, can do, and can’t do. In other words, I want to give you some idea to help you decide whether Parent/Child profiles can be useful to accomplish what you want to do.

  1. A Parent/Child profile, whether full-featured or basic, is a way to define a set of profiles (children) with the same configuration split up by some kind of rule starting from a given set of data.
  2. The parent won’t contain any data, nor aggregate of the children. It is a mere template, defining the configuration for each child.
  3. All children have strictly the same configuration, except access rights and the split rule.
  4. Access rights are set either globally at the parent’s level (each child will inherit the same access rights) or set individually on each child.
  5. If access rights are set on a child, the access rights of the parent will be ignored!
  6. Any filter set on the Parent/Child profile will be applied to each children after the data has been split.
  7. Children are analyzed sequentially on one CPU. One Parent won’t split analysis over multiple CPUs.
  8. By default, the split rule is based on the value of the parameter WT.sp, which can contain multiple values separated by space (default). The parameter and the separator can be changed.
  9. By default, the split values are compared as substrings, not exact match. Keep this in mind if you count on having 1000 children, you will have to reconfigure each one manually!
  10. Split can be defined with regular expressions.

If you have read this list and think that Parent/Child profiles are still for you, stay tuned for the following posts on more crusty details, like maximum length of split values, how to safely create, delete and deactivate children, case studies on performance issues, etc.

As always, feel free to comment or ask for specific information you would need. :)

VN:F [1.3.2_665]
Rating: 4.5/5 (2 votes cast)

Announcement: Parent/Child Profiles Posts

March 25th, 2009

Working with parent/child profiles in WebTrends made me understand that there are quite some considerations and pitfalls to take into account before using them.

My next series of posts will be about different aspects of this functionality.

Hope to find the time soon…

PS: Feel free to leave me a comment here if you are interested on this topic or if you have any specific question…

VN:F [1.3.2_665]
Rating: 0.0/5 (0 votes cast)

Multi Homed Domain Tracking - Part II

March 17th, 2009

Another challenge when tagging multi homed domain is to correctly set the first party cookie domain in the WebTrends base tag.

Unless the number of domains is limited, and you feel like creating a distinct tag for each domain (which might as well imply bigger implementation effort…), there is a small code which can do the work needed automatically.

It will simply retrieve the host name from the browsers address bar and reduce it to it’s most generic form, e.g. “.domain.tld”.

The JavaScript code snippet can be placed either directly at the end of the wtinit.js file or as inline script in the HTML document between the inclusions of wtinit.js and wtbase.js. If any other place has to be considered, it MUST be after the definition of the dcsInit object and before the call to dcsTag().

The code is the following:

var parts = document.domain.split(".");
var fpcdom = "";
if (parts.length >= 2) {
  var last = parts.length-1;
  fpcdom = "." + parts[last-1] + “
." + parts[last];
}
dcsInit.fpcdom = fpcdom;

Please be aware that this solution still sets a new first party cookie for each domain, so you still rely on the third party cookie to propagate the visitor’s ID accross the domains. However, the first party cookie will be the same for all hosts of the same domain.

Hope this comes in handy for someone!

VN:F [1.3.2_665]
Rating: 0.0/5 (0 votes cast)

Multi Homed Domain Tracking - Part I

March 17th, 2009

In my first post, I would like to share a small code I have implemented to tweak the WebTrends client-side tag to cope with web sites that have multiple domain aliases.

While having multiple domain aliases for the same web site might jeopardize your ranking in search engine indexes, the problem on the WebTrends reporting is that the same page will be split over several domains and audience has to be consolidated manually.

In order to correct this, I did the following:

  1. Add a parameter in the dcsInit object in the wtinit.js file:

    function DcsInit(){
      ...
      this.repdom = "www.unique.com"; // reported domain will be forced to this host, no matter the real domain
      ...
    }
  2. Then go to the dcsVar() function in the file wtbase.js and add the following code

    if (dcsInit.repdom != ""){
      DCS.dcssip=dcsInit.repdom;
    }

    right after the line

    DCS.dcssip=window.location.hostname;

  3. Done.

This will force the DCS.dcssip parameter to the host you specified in the variable repdom (reported domain) and you will therefore have always the same domain in your reports.

This code is based on the wtinit.js/wtbase.js version of the base tag. However, the same logic should be applicable to previous/later versions.

Voilà!

VN:F [1.3.2_665]
Rating: 1.0/5 (1 vote cast)

SiteSensor Browser Pedia Collector