Tips, tricks, and pokes, just WebTrends Analytics

Applies to WebTrends On Premises (Software)

Currently, the WebTrends report on Platforms reports on all the Apple iOS devices as one row of the Platforms report.

If you use WebTrends software (On-Premises), you can turn this one iOS row into four individual rows:  iPad, iPhone, iPodTouch, and iPod.  Just edit the WebTrends file called browsers.ini.

Your site designers will appreciate the extra data.  Designing for the iPad is a different proposition from the iPhone.

There are two or three copies of browsers.ini in your WebTrends installation folder, and you need to change all of them:  (it’s a good idea to keep a copy of the original as browsers.old or a similar name)

/WebTrends/modules/analysis/engine/8.7 (or 9.0, etc)
/WebTrends/storage/config/component/lookupdata/
/WebTrends/storage/config/engine/8.7 (or 9.0, etc)

Open one instance of browsers.ini with a proper text editor. By “proper” we mean something like TextPad as opposed to Notepad, because Notepad doesn’t play well with the system when the file is in use. With TextPad, you can [usually] take the risk of changing the file while WebTrends is running.

Do a search within the file for “iOS” and you’ll arrive at a section of four items.  It’ll be easy to see what to change when you get a look.  Change the four instances of “iOS” to “iPad,” “iPhone,” “iPodTouch,” and “iPod” in the places that will be obvious to you – you want to be changing the values of  lines starting with the string ”text=”.  Once you’ve changed those four “text=” lines,  just to be safe you should check to be sure there will be no other occurrences of “iOS” in browsers.ini.

Save and close.  Don’t forget to copy the changed file to the other two locations.

Now your platform report will show all the Apple devices separately.

Postscripts

For this tip, I started with version 15 of browsers.ini.  You’ll find the file version on the third line of the file.    If you are using a different version, this tip may not apply. 

The next time you run the updating utility for browsers.ini, the installer will overwrite these changes.  For that reason it is a great idea to keep a README.TXT file in the same place, recording the changes that you have made manually that you think should be re-done in future versions.

If you have OnDemand and would like to ask WebTrends to make a change like this one, head on over to their user forums and say so.  The forum is at http://forums.webtrends.com.  WebTrends staff participate and take note of suggestions.

Tags

Posts that WordPress seems to think are related :)

If a search engine has, in its index, listings for your page URLs that contain campaign parameters such as WT.mc_id or even utm_campaign, you have a reporting problem.  Anybody who clicks on one of those organic listings will show up in your reporting as having come from the campaign AND having come from organic search.  The latter is good, the former is bad.  Your campaign stats will be incorrectly larger than actual.

Yes, Google, Bing, and Yahoo frequently do have, in their indexes, URLs with campaign parameters.  See our Canonical URLs post for a description of several ways those superfluous parameters sneak into the index.

To see if your own site has any, take a break right now and run a search on this phrase and scan all the results:

site:yoursitenamehere.com (yes, include “site:”)

If you found more campaign-identified links than you wanted to see, there are things you can do.

One is to use Canonical URLs in your page code.  However, be warned that only Google actively honors this – Yahoo and Bing still are not complying with the Canonical URL tag after two years!

So … forget the Canonical URL tag.  Use Google and Bing/Yahoo Webmaster Tools to keep superfluous URL parameters out of the indexes.

(These instructions assume you already have Webmaster Tools accounts on both Google and Bing.  If not, you are missing out!)

Below are the steps we use.

1. Go first to Google Webmaster Tools (GWT).  Do not go to Bing/Yahoo first.
2. In Google Webmaster Tools, go to Site Configurations >> Settings >>Parameter Handling tab
3. GWT will show you a list of parameters that it has found during its crawls.
4. For those parameters you want Google to omit from the URLs in its index, change the Action to “Ignore.”
5. Print the list to paper – you’ll need it for the next step.
6. Save and close GWT
7. Go to Bing Webmaster Tools
8. In Bing Webmaster Tools, go to Crawl >> Crawl Settings
9. Using the list you printed, enter all the parameters you want suppressed

The tip embedded in the above is to use Google Webmaster Tools to get a pretty complete list of all possible parameters. In fact, you’ll probably see parameters you aren’t aware of or have forgotten about.  Then, with your sure-to-be-complete list of parameters, it’s easy to fill up the Bing/Yahoo list, which is a blank slate with no starter list like Google has.

What if the Google list shows parameters that you don’t understand or are not familiar with?

Here’s a second tip that we discovered by accident.  You can coax information from the Google Webmaster Tools parameter list that will help you figure out what some of the parameters are all about.  It won’t be a complete answer, but it will help.

You have to be using Internet Explorer or Chrome, probably Firefox.  Opera, our favorite ultra-fast browser for home use, doesn’t work for this.

The GWT list of parameters looks something like this:

In the screen shot, note that the second column, Action, is all drop-down lists.  If any of your rows are NOT dropdown lists on your screen, click on the “Edit” or “Reset” link at the far right.  The second column item should turn into a dropdown list.

With your mouse, click on the heading or the first parameter, drag, and copy it to the clipboard.

Paste it into Word.  Not Paste Special, but Paste.  It should paste as messy HTML, with extra stuff, like this:

Note the red arrow above.  The MS Word pasted copy shows TWO dropdown menus per row, not one!  The second dropdown is live.  Click on it and you’ll see the known values of the parameter, as below:

This second dropdown has been there all along, but was coded to not display in a browser window.  Copying and pasting it to Word just happens to make it visible.  Cool eh?  You can also use a debugger such as Fiddler to break the invisibility in the browser window, but using Word is much faster.

Now you have more information on what the mystery parameters are all about.  Some will have only one value and might be typos in the code.  Others, like “denomination” above, is revealed to have values of 10, 20, 50, 100 and so on … which we immediately recognized as denominations for gift card purchases.  Not a necessary parameter.

So, with the new information, you can set even more parameters to “ignore” and clean up your organic listings further.

While you’re in Webmaster Tools, especially the Google one, look around.  There is some very useful stuff in there.

Tags

Posts that WordPress seems to think are related :)

Applies to:  WebTrends On-Premises, i.e. WebTrends Software

Situation:

1. Your WebTrends software has routine profiles that are scheduled to run every 4, 12, 24 (or whatever) hours
2. You also have a one-time situation … you have to back-analyze a ton of retroactive data which will take many hours of WebTrends processing
3. You don’t want the back-analyzing profile(s) to clog up the Scheduler and prevent the routine profiles from processing on time.
4. You want to start the back-analysis profile(s) as soon as possible, but you want it/them to be out of the way when it’s time for the routine profiles to run.

There’s an easy way to keep gridlock from happening. 

Edit the back-analyzing profile(s) and  fiddle with Analysis Throttling and Scheduler as follows: 

In the Analysis Throttling admin panel:  (within the edit function of the individual profile)

• Set “Maximum Data to Analyze” to be something that will take an hour or so to run.  For some profiles, this would be one day of data.  For others, it could be a month of data.  If you don’t already have an idea of analysis time for a day of data,  the Scheduler’s Job Status section can help.  Find the start and end time for the last run in the list of details.
• Turn off “Rerun analysis immediately after maximum amount of data is analyzed.”  In other words, you want the profile to analyze for an hour or so, then close down (i.e. get out of the queue).

In the Analysis Scheduler: (again … you are doing this within the profile’s editing interface)

• Set the analysis to happen every hour (the default setting is every day).

That’s all.  The only thing you need to do after the back-analysis profile(s) is finished is remember to set these settings back to normal, if you want that profile to continue to process new data  from now on.

How it works:  The back-analysis profile(s) will turn off after analyzing x days of data, whatever you specified in Maximum Data to Analyze.  At that point, everything in the queue moves up one step closer to the front … including your routine analysis event, which will the queue at its appointed time.  The Scheduler will put the back-analysis profile into the last position the analysis queue sometimes in the next 1-59 minutes.  The back-analysis profile will pick up from where it left off once it works its way to the front of the queue.

Caveats:

This method can cause some minutes’ delay in the start of the routine profiles compared to their scheduled time, but you gotta admit it’s far better than being stalled for many hours in the queue while the mammoth profile(s) continue processing. 

 This method also can delay the back-analysis profiles somewhat if you don’t find the right balance between Maximum Data to Analyze and Scheduler intervals. 

Tags

Posts that WordPress seems to think are related :)

This post is just a redirect to Jacques Warren’s fine post on WebTrends’ Remote Upgrade Services.  If you use WebTrends software (aka OnPremises) and you are a version or two out of date, and if you’re  nervous about doing the upgrade, read it.  The upgrade process has gotten a lot more complicated in the last couple of versions due to the big-time underlying changes they’ve brought to the product.

If you have ever met Jacques Warren, you know that he is one of the most experienced WebTrends users outside of WebTrends itself … the kind of consultant we need lots of.  Wish he would consider moving to my neighborhood …

To quote Jacques:  “In a few words, [WebTrends] basically takes care of the most complex parts of the upgrade. And here’s the kicker: you can be as far back as 7.5b and they will upgrade you to 9.2a, no problem! No more intermediary installations! Those at a minimum familiar with the topic are going “Wholy Cow!””

Thanks, Jacques, for sharing the experience.  And thank you very much, WebTrends!

Tags

Posts that WordPress seems to think are related :)

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:

1. 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)
2. 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.
3. Added “drilldown” or “dd” if the dimension is a drill-down, available in the Based On tab.
4. 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.

 PostScript:

(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?

Tags

Posts that WordPress seems to think are related :)