Our prior post on WebTrends Custom Dimensions and why you must know if they are hit-based or visit-based got a big, positive response back when we published it.
Yesterday we were forcefully reminded of the visit-based and hit-based distinction when we successfully created, and very nearly published the data from, a custom report in which we had botched the job of matching dimension type with measure type. Hit-based dimensions can only have hit-based measures! Hit-based primary dimensions can only have hit-based secondary dimensions! Otherwise, the results can look very, very weird. Or, in our case yesterday, not weird enough to set off alarm bells immediately but still utterly wrong.
We dodged a bullet on that one because we noticed it … eventually. Consequently, this morning I relabeled all of our custom dimensions in order to never do it again.
Which brings us to the gist of this post – create labels for your custom dimensions that will help you avoid mistakes later.
Here’s what I did to annotate the labels with important configuration information:
- Added text to the end of the label showing how “When to Collect Data” tab was set up:
- “all-hits” (Data is collected on every hit. This is the WebTrends default. It’s a hit-based dimension)
- “first-occ” (Data is collected only for the first occurrence in the visit. Visit-based dimension)
- “last-occ” (Same as above, but for the last occurrence in the visit)
- “if-URL-is” (Data is collected only if the URL matches the specification. Hit-based dimension)
- “most-recent” (Data is collected fromVisitor History for the visitor’s most recent value of the dimension. Visitor-based dimension)
- Added “transl” if the dimension values are transformed using a lookup table (using the Advanced button in the Based On tab). This is important because those dimensions may be based on something generic, such as “ID,” but the translation makes they applicable only to specific uses of the ID parameter.
- Added “drilldown” or “dd” if the dimension is a drill-down, available in the Based On tab.
- Added “extract” if the dimension uses anything other than “Full String,” the default. Doing substring extractions is an option in Based On.
Also, I made sure that the main part of the label is clear about what the dimension is based on. Note that in the above examples everything is labeled Query parameter “<parameter-name>”.
- This method is not everybody’s cup of tea but I want to offer it as a decent possibility for keeping chaos down. I’ve tried bucketing things but too many dimensions fit into more than one bucket resulting in constant guessing & scanning of lists.
- The quote marks make it easier to visually scan
- Another way of accomplishing clarity as to dimension basis would be to use Categories, if the categories are named after the dimension’s basis. When choosing a dimension during a custom report setup, the dimensions in the dropdown list are grouped according to Category so this works pretty well.
- I ended up with a huge list of dimensions in the Query Parameter category because that’s what most of our dimensions are based on. Huge. Hundreds.
- Having a huge list is okay for us if the parameter names are explicit, i.e. are exactly how they appear in URL. When setting up custom reports we generally double-check against the actual site or use other ways of being sure about the parameter name.
- Since I work at an agency, parameter names tend to vary from client to client (productID=, prodID=, pid=) which is why using the exact name is the only way to be sure of choosing the right one.
Do you have a good way to label dimensions (or anything else) in WebTrends? Would love to hear about it.
(Hello WebTrends folks!) Here’s a screen shot of the Dimensions display in the WebTrends Admin, smushed horizontally (in other words, there’s a lot of actual horizontal room full-screen). Don’t you think there is sufficient space for another column having to do with the dimension type? Does this post convince you that users need this information? Hope so. Let us know?