Hello all
I’m back from my unusually long summer break, hope to be able to write new articles soon!!
Hello all
I’m back from my unusually long summer break, hope to be able to write new articles soon!!
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!
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
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).
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 |
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):

Here is how to create it:
SOURCE,LABEL
WT.srch,Paid Search
WT.mc_id,Paid ReferrerRemarks:
Any remarks or questions are welcome!
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.
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.
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…
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!
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:
function DcsInit(){
 ...
 this.repdom = "www.unique.com"; // reported domain will be forced to this host, no matter the real domain
 ...
}
if (dcsInit.repdom != ""){
  DCS.dcssip=dcsInit.repdom;
}
right after the line
DCS.dcssip=window.location.hostname;
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à !