Adding Windows 7 to the Platforms report

Windows 7 is here, sort of. You can add it to your reports through the automatic .ini file updater or manually. Here’s how.

Yes, Windows 7 is here.  Sort of.  Under the covers, it’s actually Windows NT 6.1.

You can get your Platforms report to show Windows 7 traffic by downloading and installing the newest browsers.ini and keywords.ini files, with the Browsers.ini And Keywords.ini Updater (can we come up with a shorter name?  BKU?) which is here.  The updater requires version 8.1 or newer.

If you have an earlier version, you can manually update the browsers.ini file, as follows:

Step 1.  Find the browsers.ini file(s)

There are usually three or four copies of the file browsers.ini on the typical WebTrends installation, and there could be extra copies on other servers if you use distributed architecture. You’ll need to change all of them.  Typical locations are:

/WebTrends/modules/analysis/engine/8.0d (8.1, 8.5, etc)
/WebTrends/storage/config/component/lookupdata/
/WebTrends/storage/config/engine/8.0d (8.1, 8.5, etc)
/WebTrends/

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.

Step 2.  Change the Platforms list.

Find the [Platforms] section and go to the end of the [Platforms] list. Find the last numbered entry. Add an entry like this (the number may be different for your version of the file):

Platform56=WIN_7

Step 3 – Add the [Platforms] section specifications. 

Go to the top of the [Platforms] specification list (groups of three or four lines).  (I have no idea why Platforms is in reverse order from Browsers and the most recent ones are at the top instead of the bottom.  Maybe order doesn’t matter as long as the main list is numbered.)  Anyway, add a blank line and then this:

[WIN_7]
log1=WINDOWS NT 6.1
text=Windows 7

Step 4.  Save and close the browsers.ini file.

Step 5.  Copy the file to all locations where there’s a browsers.ini.

Step 6.    Restart your Scheduler Service

Cool custom measure column: Number of first-time visits

Add a column that shows the number of first-time-ever visits that you’re getting from your various traffic sources. WebTrends custom measures fun.

This is a nifty extension of the generic create-custom-measures-based-on-KPI-pages post that we did a couple months ago.

You already can easily get reports on New vs Return Visitors, and you can use New vs Return as a dimension combined with something like Campaigns as another dimension.  Or you can use New and Return as filters in custom reports.  This is a little different, and we think it’s actually better.  It’s not a dimension (a row called New or Return), it’s a measure (a column, with numbers under it).

We’re calling this measure “First-Time Visits” and it makes a column that shows the number of visits that were visitors’ first-ever visits.  It’s very cool in reports on campaigns, search terms, search term groups, or other “source of visit” reports.

It uses one of the important, but hidden, parameters that are created by the very very smart SDC server when it processes hits.  It’s possible only if you collect data using SDC (SmartSource Data Collector).  Normally, WebTrends uses this parameter in reports such as New versus Return Visitors.  We piggy-back on it for this special custom measure.

Reality check

You DO want to know which traffic sources are bringing in first-timers, right?  Of course you do.

Think about it.  One of the big wins for any banner campaign or affiliate site or paid search ad or organic search keyword is bringing first-timers to the site.   To introduce people to your wonderful, engaging, helpful, valuable and well-organized site and to let the site do its magic and induce these newcomers to buy, come back over and over, or whatever it is that your site is supposed to do.

How-to

Here’s how to make a First-Time Visits measure, in detailed step-by-step for those who haven’t done something like this before.   We’re following the procedure from the create-custom-measures-based-on-KPI-pages post .

  • Open the WT admin screen and go to:  Report Configuration >> Custom Reports >> Measures >> New Measure
  • Name the measure something like “First-Time Visits”.  Same for the column name. 
  • “Value to Base On” is Query Parameter and “Parameter Name” is “WT.ti” – weird, but trust us. 
  • Ignore the Advanced button and go to the next screen.
  • “When to Measure” is “Hits that Match Specified URL.”  It’s the last choice in the dropdown menu. 
  • For “Do you want to sum this measure across the visit” choose “YES.”
  • In the “URL Expression” window, enter “*” using Equal To.
  • Click on “New URL Parameter” to open the URL Parameter window.  In that window, enter “WT.vt_f” as the parameter name.  Yes, WT.vt_if is the magical internal SDC parameter that SDC sets to a value of “1” if a visitor doesn’t have a pre-existing WebTrends cookie.  (it sets it to a value of “2” at other times, but we only want the 1’s.)
  • Parameter Value should be Equal To the number “1,” using the Text radio button
  • Click Done.  You’ll go back to the mean Create Measures screens. 
  • Go to the Format tab and set it to “No Currency” and 0 decimal places
  • Save

Now you’re ready to add the measure to an appropriate custom report.  It works great with a report where the dimension is Campaign ID (WT.mc_id on entry page, in other words). 

IMPORTANT:  Note the above statement.  We get mail about this from people who skip over it.  When adding the measure to a custom report, specify the Method as “COUNT”.  The default is Sum.  Don’t use Sum.  Use COUNT.

Postscript:

Do we need to mention that people who delete their cookies or use multiple computers will mess up any means of identifying them as repeaters or first-timers?  Or that browsers that refuse persistent cookies can’t be classified as repeaters or first-timers?   The results won’t be perfect.  But they’re pretty darn useful anyway.

Making a blitz profile

The WebTrends software version allows data re-analysis any time you want. Sometimes you want it SOON. Here’s how to make a speedy re-analysis profile for one-time use.

Applies to:  Software, especially software with Custom Reports ability

Let it be known that we Outsiders are fans of the software version of WebTrends.   You, astute reader, may have noticed this in other Outsider posts.

It’s really important to be able to re-analyze data.  Even with hosted solutions that use big ol’ queryable databases, I can personally guarantee that I will constantly need something outside the cube structure.   That means re-analysis, period.

And sometimes I need it fast.  The most common emergency is when I invent a new custom report — and need results right away for the most recent month.

The proper, professional, calm, workmanlike way would be to modify an existing profile, rollback and re-analyze.  Or  clone and modify an existing profile then analyze the last month of data.

But if I’m in a rush, I do a one-time blitz analysis and worry about the “proper” way when I have the time.

In order to do this, I keep ready an empty, stripped-down profile named “Blitz” that I clone, add the new report to, and get results from in a fraction of the usual time.   Like, um, 85% faster.  I’ve clocked it.  (Think:  if re-analyzing all of a month of data takes an hour with your usual profile, a blitz profile could do the same thing, just for one custom report, in 9 minutes.)

The Blitz profile has the following settings.   As far as I know, these are all the settings in a profile that can be stripped off.  If you know of any others, let me know!

(Note:  Not all of them will apply to you.  For example, you may not have any URL Search & Replace operations at all so there’s nothing to turn off.  Or,  the custom report you want to blitz may require Visitor History so you shouldn’t disable VH.)

  • Turn off Visitor History
    •   Analysis >> Visitor History
  • Turn off Internet Resolution and GeoTrends
    •     Analysis >> Internet Resolution
  • Turn off Retrieve HTML Page Titles
    •   Analysis >> General
    • (this should be off anyway if you use SDC data)
  • Increase Analysis Throttling time if you are analyzing multiple days of data (don’t make it too high, but I’ve done up to 30 days at a time for modest-size logs)
    •     Analysis >> Analysis Throttling
  • Turn off Fix Out Of Order Records
    • Analysis >> Resource Control
  • Turn off URL Search & Replace operations
    • Advanced >> URL Search & Replace
  • Turn off irrelevant analyses– other custom reports, content group definitions, path analyses, URL parameter analyses, and so on
    • Advanced >> Content Groups (etc)
  • Turn off all report periods except Monthly (even for a few days’ data)
    • Reports >> Report Periods
  • Put your logs on the same machine as the WT program (this is more than just a setting)
    • Copy the logs to a location on the analysis machine
    • Make a new data source
    • Change: Analysis >> Data Source
  • Turn off all of the Standard Reports
    • Advanced >> Reports (uncheck the little box at the top of the list)

(The last one, Turn Off Standard Reports, might be something you’ve never known about.  It’s the little box called “Enable Standard Reports” at the top of the Custom Report list.  Turning it off has a one caveat if you are blitzing a custom report that uses many of the standard dimensions such as content groups, search phrases, browsers, platforms, search keywords and so on.  (Below in the comments, we have a list of those we think can be affected, but it’s turning out to be an incomplete list.)  For these, WebTrends must run the related standard report.    If that’s your situation, you’ll either have to keep Standard Reports enabled in your speeded-up profile, OR go ahead and disable standard reports but use this hack:  add a line to the [reports] section of the profile’s .wlp file that enables the related standard report. )  (Below in the comments, we have a list of those we think can be affected, but it’s turning out to be an incomplete list.  Without a lot of research that I don’t have time for, I’m going to say … if you really need that profile to happen in a hurry and don’t want to take a chance on your targeted report depending on Standard Reports, then don’t turn off standard reports.)

 
This list may be incomplete and there may be exceptions to individual items that I don’t know about.  Please let us know!

 

P.S. Wouldn’t it be nice if the WT profile definition interface had a way to selectively disable/enable individual standard reports?   Since the *.wlp file has individual lines for each standard report, how hard could it be?

Reasons for seeing your own site in Referrer reports … and what you can do about it

In Referrers reports, your own site is often one of the top items. We explain why, and what you can do about it in your WebTrends settings.

On the all-important Referrers reports (Referring Domain, Referring Site, Referring Domain Type, and Referring Page), there are always two puzzling entries – the Direct Traffic item (see this post about Direct Traffic) and the inevitable listing for your own site.

How can you be seeing visits referred from your own site?  More importantly, what should you do about it?

The reason is easy to understand once you “get” what a visit really is in the analytics world.

Empathize with the visitor for a second.

When, exactly, is the visitor really done with your site?

  • When they click on one of your links that goes off-site?  What if they come back right away?
  • When they type something else in the browser window?  What if they come back a couple minutes later?
  • When they close the browser window?  What if they have your site open in more than one window? 
  • When they back-button to the search engine window that brought them there in the first place?  What if they come back to your site with another click on your listing?
  • When they switch to a different tab in the browser?  What if they come back to that tab?
  • When they leave your site open and go to a meeting?  What if they start clicking again when they return to their desk?

Get the picture?

For all of these, my question to you is:  do you think the visitor is done with your site when they “leave”?  Is the visit really over?

In many, many cases of the above behaviors, the visitor comes back to your site later.  The reality is that visitors are distractable and Internet browsing is circuitous.  It may not be realistic at all to assume the visitor is mentally done with your site when they do the above actions.

The other problem with these definitions is that, except for the first one, WebTrends has no data on them anyway.  WebTrends, and no analytics package really, can know that the browser window was closed or the visitor switched to another site (other than by offsite links on your site).  Browsers follow protocols set up long ago by a central group of wise people (the W3C) and, for privacy reasons, that information does not get transmitted by browsers and never has.

Empathize with the WebTrends program for a second.

It’s chunking along, assigning each hit to a visit (using a cookie, for example), and keeping track of all these open visits while they’re happening.  It (the WebTrends program) has no way of knowing when a visitor is done with their visit.  None!   It cannot tell when a different site fills the browser window or when the browser is closed by the visitor.

WebTrends’ can only ASSUME a visit is over when it sees a long period of nothing happening.

Consequently, WebTrends has a time-out setting.  If x number of minutes go by without any file requests, WebTrends marks the visit closed and adds that visit’s various stats to various internal tables.

Out of the box, WebTrends’ visit timeout is 30 minutes of inactivity.   So if somebody leaves a page sitting on their screen for 31 minutes, then they come back to the page and click on something, that new click will be the bucketed as the first click of a new visit.

And in this particular instance, the referrer, i.e. the page of origin of that click is …. the site itself!

That’s the explanation of what’s happening.  Now, what should you do about it?  Here are possibilities.  (The first is a necessary mindset and the last one is IMHO the best action to take.)

  1. Adjust your mental labeling.  It helps to think of the self-referred visits with a special name.  I call them “visit second halves.”  “Self-referred visits” is not a good label because it implies that they really are visits.  To me, they’re not.  They’re just visit pieces.
  2. Adjust your stats.  You get a “visits” number from the Overview Dashboard and various places, but is it really the number you want to use?  A much more accurate visit count is the total visits number MINUS the second halves.  In other words, [number of visits (from Overview) minus visits referred by your own site (from Referrers)].  Yes, if you do this arithmetic, your total visits number goes depressingly down.  But at the same time, the size of a typical visit goes up!  And ratios like “percent of visits with a conversion” goes up also.  (Note that you’ll have to do these adjustments to your stats outside of WebTrends, for example in your Excel exports that are your final deliverable to your end users.)
  3. Realize and accept that your campaign attributes will underestimate conversion because of this.  The reason: if the campaign attribution happens in the first visit (the landing page), and the conversion happens after the visitor’s pause in activity, the conversion can’t be connected by WebTrends to the campaign.
    • Well, there’s one way — set up your campaign reports to use Most Recent Campaign.  Unfortunately this will connect some conversions to old campaigns, and if you’re interested only in campaigns that your visitors experienced very recently, you’ll need to look at short timeframes, like a day or two.
  4. Change WebTrends settings to reduce the number of second halves, i.e. merge as many second halves as possible with their first halves.  You need the software to do this, not On Demand. The setting that does this is the timeout and, as far as I know, WebTrends software is the only program anywhere that allows you to do this.  The longer the timeout, the fewer visits will be split in pieces because of the timeout.
    • The timeout is configurable by you for a given Session Tracking choice — in the Session Tracking area (Web Analysis >> Options >> Session Tracking >> General tab).  You can set up several different Session Tracking definitions, each having different timeouts, because different profiles may need different timeouts.  For example, if you really really need to have your WT stats on the same basis as other analytics programs, you’ll want at least one profile that uses 30 minutes.
    • I, personally, set my timeouts to be 90 minutes, simply because my mental model of a visit allows the visitor to take a lunch break or have an hour-long meeting.
    • Some analysts prefer 2-4 hours
    • There’s one analytics package out there that uses 24 hours, or at least they did when I was using that package.
    • WebTrends has no maximum, but the higher you set it, the more likely it is that WebTrends will break because it has to keep more and more visits in memory at one time.

Postscript:

There is another reason for seeing your own site as referrer if you use SDC tags for data collection, and it’s worth mentioning here (thanks for the nudge Michael M!).  What if a visitor lands on a page that doesn’t have an SDC tag?  Any clicks going from that page to the rest of your site will be recorded as originating on that un-tagged page.  The visitor’s SECOND page view will be mistakenly shown as the entry page, and the referrer will be your own site.   One way to check on this is to look at a report on “Referring Pages” (not Referring Sites or Domains) — look for any of your own site’s pages that are listed as referrers but don’t show up in the Pages report.

Finally — Don’t solve the problem by filtering out visits that are referred by your own site!  It’s appear that you’ve tidied up the referrers report and fixed your total visits number, but any KPIs that happen during second halves will be lost.

Seven ways to annotate your reporting

There are days when I think the best possible thing I could do for end users of web analytics reports would be to give them more and better … explanations. Here are several ways you can help your users by adding or modifying the language of WebTrends reports.

There are days when I think the best possible thing I could do for end users of web analytics reports would be to give them more and better … explanations.  NOT more data, but good clear labels, descriptions, and, well, explanations.

Here are several ways you can help end users by adding or modifying language in WebTrends reports.  I’m mostly talking about v8.5, though most of it applies to earlier versions.

Profile name — When in the profile editing mode, this is the first field in Analysis >> General.  You’re already using it, without doubt.  What you enter here will appear on the list of profiles and at the top of every report (in 8.5 it’s in in uselessly tiny type just below the uselessly huge “Analytics Reports” headline; in 8.0 and 8.1 it was reasonably sized and boldface).   The name field can accept a lot of characters and it will wrap, in the list of profiles.  But when displayed at the top of a report it gets truncated to about 50 characters, so you might want to consider this your limit. 

Profile title — Uh, didn’t we just deal with this?  No.  That was the profile name, this is the profile title.  Confusing, yes, and you can ignore this section if you wish.  But have you ever noticed the tab “Reports” which contains a subtab “Report Header”?  On that page, there’s a “Title” field that accepts about 50 characters.  (Hello WebTrends people, this field is broken in 8.5, and what you enter in this field doesn’t show up anywhere.)  In 8.0 and 8.1, however, if populated, this field supersedes the Profile Name when you’re looking at report results.  (Hello WebTrends people, the screen says it defaults to the Profile Description, which is wrong – it defaults to the Profile Name.)  Anyway, when working properly as it does in 8.0 and 8.1, using this field simply means you can have a profile appear as one name in your list of profiles and as another friendlier name for those looking at the report results.   Not many people would care, but I do, and I’d like to see it fixed in 8.5.

Profile description — Another little-known field, but this one actually works.  It’s the second field in Reports >> Report Header (the messed-up one in the previous paragraph is the first field).  Profile Description accepts 255 characters (too few for the important job of explaining what specialized profiles do!).  What you enter in this field appears in tiny type in a crowded spot below the profile name. 

Okay, I’ll be nicer to WebTrends for the rest of this post.

Custom Report name and title —  If you make custom reports, you’ve done this.  Looks like the limit is about 135 characters. 

  • If you want the report name to appear in the Table of Contents without wrapping, you need to limit it to about 25 characters. 
  • And, very important for ODBC users among us, too-long custom report names/titles can kill the ODBC connection.  The limit for ODBC seems to be about 70 characters.)

Custom Report description — When you create a custom report, this is the golden opportunity to tell your readers what the report is about, how to use it, maybe something about threshholds or interpretation.  You have a LOT of room – at least 1500 characters, maybe more.  And, new to 8.5 apparently, line breaks you put in your text are preserved!

Custom Report Help Card text — Did you know you can affect what shows in the Help Cards that appear below the report tables?  You have opportunities to insert your own text whenever you define a custom report, dimension, measure, or filter, and it’s always offered to you as the last field box in the definition screens.   If you do a lot of custom report work, using the Help Cards can help your users and SYA later on when you’ve forgotten exactly what went into those components.

Standard Report description — Warning … this is a hack.  The GUI doesn’t allow you to edit standard reports (such as the Pages report or the Browsers report) but if you are lucky enough to be using the software version of WebTrends, you can go through the back door. 

No, WebTrends does not support what I’m about to tell you … 

There is a language configuration file for the interface wording.  With a text editor (and proper use of backups and carefulness) you can edit reporting text.  The file is called english.rpl (there are also versions for other languages) and it’s in the /wtm_wtx/template/ folder in the WebTrends installation. 

Here’s an example line from this file:
 
<TopPages_ShortDescription> = {{This identifies the most popular web pages on your site and shows you the number of visits for each, and displays the average length of time the page was viewed.}}

So maybe you think the word “popular” is dumb and you don’t want all the “you/your” stuff.  And you’d also like to clarify the measures.  You could change it to:  

<TopPages_ShortDescription> = {{This identifies the most-visited web pages on the site.  The table shows the number of visits for each page (regardless of how many times the page was seen in a given visit) and the average length of time the page was displayed (but only for those page views that were followed by another page view).  Note that we have decided to count any click within a Flash application as a “page.” }} 

I know we all think we could explain reports to our end users better than WebTrends can, so you’re probably really tempted to give it a try.

Some tips:

  • Make sure WebTrends isn’t processing anything when you change this file.  (Actually, I violate this rule all the time because the text editor I use, TextPad, allows editing of a file without locking out the program.  Knock on wood.)
  • Use TextPad (or another safe text editor, not Notepad, definitely not Word) to open the file. 
  • Look around the file carefully before you make changes, to get accustomed to what’s there.
  • In our experience, you can safely make changes to anything inside double curly brackets i.e. {{ … }}. 
  • Do NOT make changes to anything inside double percents i.e. %% … %% even if the percented strings are inside double curly brackets {{ … }} ! 
  • Do NOT make changes to anything inside angle brackets < … >
  • I strongly suggest limiting your changes to the ShortDescription lines.  You’ll get the most bang for the buck without getting into too many interdependencies.  But, hey, it’s all at your own risk.
  • Don’t get carried away with length.  You probably could break something if you make strings too long.  (If you learn anything about limits, please tell us)
  • Make a backup of the file before changing it.
  • When done, reboot WebTrends or restart the services to get the changes to take effect.

Final thoughts 

This post doesn’t talk much about names and labels, especially for content groups, column headings in custom reports, and so on.  Let it simply be said that you have a lot of opportunity for helping end users by being careful with these.

And, before you ask, WebTrends sadly doesn’t have a way to add report annotations on the fly, for example by end users when they are looking at report results.  Nor does WebTrends allow any annotations of graphs.  Maybe some day.