Under-used Feature – % change over time

Comparing “now” to “then” is the possibly the most frequent kind of comparison in our business.
WebTrends makes it easy to compare time periods and even calculates percentage differences for you.

Comparing “now” to “then” is the possibly the most frequent kind of comparison in our business.

WebTrends makes it really easy to check changes and even calculates percent differences for you.

Have you ever really looked at all those calendar choices?  The ones that show percentage change are the double calendar icons.  There’s one for standard time periods (whole month, whole week) and another for non-standard comparisons (9 days of data, or 7 days but not a standard week).

Almost all WebTrends reports, including dashboards, will show you side-by-side numbers for your two time periods, with percentage change in a separate column.  (The reports that don’t have to do with path analysis.  There may be others I haven’t noticed.)

The main thing you have to remember when setting these up is that the percentages are Column A divided by Column B.  The directionality is counterintuitive for some people.  But if you get it wrong, you don’t have to start over.  There’s a handy “transpose” button in the calendar bar that will switch positions immediately (below).

I use the comparison feature constantly, i.e. weekly, mostly checking for big changes for individual pages, individual entry pages, campaigns, and individual referrers.  Big sudden changes are flags for further digging.

I also use it to get quick year-over-year stats.  Very helpful.

It’s easy to compare month-over-month if you zoom out using the icon called “zoom out” (below).  The calendar format changes from days in a month to all the months in a year, for example.  (In the screen below, note that February is on the left, January on the right — to get, in the tables, percent change from January to February.)

 

Finally, a word about the Custom Calendar comparison (comparing non-standard date ranges).  The custom calendar date selection process forces you to compare equal time periods.   (Otherwise, the percentage changes won’t be meaningful, ya know.)  So, if you change the calendar on the left from a 9 day period to a 5 day period, the calendar on the right will change automatically to a 5 day period.  The start day stays the same, only the end date changes.  That’s why, in the custom calendar interface shown below, the calendar on the right doesn’t have a way to change the end date.

Need we mention … when comparing custom date ranges, you’ll get more meaningful data if you make sure that both time periods start on the same day of the week, or at least include the same balance of weekdays.  Otherwise, you may find you’re comparing a 9 day period containing two weekends to a 9 day period containing only one weekend.  For most sites, this won’t give a true picture of the relative differences.

Cool custom report: Bounce

How to create WebTrends custom reports that show bounce activity for search terms, entry pages, campaigns, referrers.

Bounce rate is kinda hard to interpret.  Sometimes it’s good that your visitors find everything they need on the landing page.  Often it’s a bad sign – they didn’t see the relevance of the landing page to their search, or they maybe they found all they were after but you’d rather they also looked at what else you offer.  

You, as analyst, get to do the interpretation.  We, as Outsiders, want to help you obain the data to interpret.

Why Bounce Rate?

Avinash Kaushik and Rich Page, among others, have often talked about bounce rate.  You should be looking at bounce rates for individual pages, pay-per-click keywords, campaigns, campaign messages, and so on. 

Examples:

  • Site A example:  We saw a very high bounce rate for certain paid keyword ads that landed on a product category page, when the keywords were clearly about products, not categories.  People weren’t seeing the link from the category to the product so they left in large numbers without getting below the category level.  We had thought we were being smart by exposing people to several related products through the category page, but it apparently wasn’t working out that way.  So we changed the landing page to the product page and bounce rate went down a lot — because after getting the information they were looking for, people still took a look at other products. 
  • Site B example:  Similar situation, but different.  We saw a very high bounce rate for paid keyword ads that landed on an individual product page, when the keywords were, as above, about products.  People were apparently getting all the information they wanted and leaving without realizing the site offered a number of related products.  It was a flipped-over version of the previous example, but people arriving on the product page were, similarly, not looking at the category’s other products.  We used the high bounce rates to get funding for adding “related products” functionality to the product pages. 

WebTrends and Bounce Rate

First off, we don’t have a way to get calculated bounce percentage statistics (67%, 23%) out of WebTrends.  Sorry. 

But we can show how to get the next best thing – total entry page visits and single page visits in the same report.  When these two numbers are next to each other, it’s not hard to see problems by eye and if you export to Excel, it’s easy to calculate exact percentages. 

The reports will look something like this.  Note the center comment bubble – it’s the point of this report, the calculation needed to get bounce rate for a page. 

Making the Custom Report

The Primary Dimension

The primary dimension is whatever you want a bounce rate for.  It must be a visit-type dimension having to do with entry pages, meaning something that applies to the whole visit.  Entry page, search term, marketing campaign, referrer all qualify, and so does a query parameter on the entry page.  See our previous post on visit- versus hit-based custom dimensions for more information.

The Secondary Dimension

The secondary dimension is a new custom dimension, let’s call it “Page View Bucket,” which shows “One” if the visit was one page long, “Two or More” otherwise.  A visit of 1 page is, of course, a bounce. 

You have to create this dimension and it is based on the Page Views dimension.  But, for this dimension, go further than usual and use a lookup table to collapse the long list of results you get from the Page Views dimension (visits of length 1, 2, 3, … 100 or more each in their own row) into just two rows, i.e. single page visits and longer visits.  

The trick of using a lookup file (a.k.a. translation file) that turns a long list into a short list is cool.  Here is how. 

The Lookup File   

  1. Create the lookup file and put it on the server (see “The Details” below).  If you use WebTrends On Demand, you will have to submit it to them and have them install it.  Lookup Table provisioning may or may not already be allowed in your account, talk to your account manager.
  2. Tell the WebTrends program about the name and location of the lookup file so it will appear in the list of lookup file choices.  You do this by defining it as a Custom Lookup Table.  You’ll find “Lookup Tables” as the next choice below “Filters” in the custom-report building menu.  (WebTrends On Demand tech support will do this for you, see above.)
  3. Go into the edit screen for the dimension, click on “Advanced” (in the Based-On tab) and check the box for “Translate Substring Retrieved Above.”  When you check the box, WebTrends will show you the list of available lookup files; choose yours.  You’ll have to tell it what the Key and Value columns are; they are A and B for the file we supply.

The Details of the Lookup File

 Copy and drop the following into a text file.  You can call it something like “bucketize_1-99.txt” or something.  If you use the software (and aren’t uploading it to On Demand tech support) we suggest putting the file here: 

/WebTrends/storage/config/wtm_wtx/datfiles/datasources/ 


1,One
2,Two or More
3,Two or More
4,Two or More
5,Two or More
6,Two or More
7,Two or More
8,Two or More
9,Two or More
10,Two or More
11,Two or More
12,Two or More
13,Two or More
14,Two or More
15,Two or More
16,Two or More
17,Two or More
18,Two or More
19,Two or More
20,Two or More
21,Two or More
22,Two or More
23,Two or More
24,Two or More
25,Two or More
26,Two or More
27,Two or More
28,Two or More
29,Two or More
30,Two or More
31,Two or More
32,Two or More
33,Two or More
34,Two or More
35,Two or More
36,Two or More
37,Two or More
38,Two or More
39,Two or More
40,Two or More
41,Two or More
42,Two or More
43,Two or More
44,Two or More
45,Two or More
46,Two or More
47,Two or More
48,Two or More
49,Two or More
50,Two or More
51,Two or More
52,Two or More
53,Two or More
54,Two or More
55,Two or More
56,Two or More
57,Two or More
58,Two or More
59,Two or More
60,Two or More
61,Two or More
62,Two or More
63,Two or More
64,Two or More
65,Two or More
66,Two or More
67,Two or More
68,Two or More
69,Two or More
70,Two or More
71,Two or More
72,Two or More
73,Two or More
74,Two or More
75,Two or More
76,Two or More
77,Two or More
78,Two or More
79,Two or More
80,Two or More
81,Two or More
82,Two or More
83,Two or More
84,Two or More
85,Two or More
86,Two or More
87,Two or More
88,Two or More
89,Two or More
90,Two or More
91,Two or More
92,Two or More
93,Two or More
94,Two or More
95,Two or More
96,Two or More
97,Two or More
98,Two or More
99,Two or More
> 99,Two or More 

Note that the last line is “> 99”.  It’s the last line WebTrends will show for reports with this dimension; everything above 99 goes into this bucket with the WebTrends label “> 99”.  Because WebTrends won’t show granularity above 99, this is as far as you can go with your buckets.

Postscript

If you’ve gotten this far, you probably realize that this lookup table business is very versatile.  You can modify it to produce any kinds of buckets.  For example, we could have made the above to produce “One or Two” as one bucket, “Three to Ten” as another bucket, and so on.

Cool Custom Report: Campaign latency, pt 1

Campaign attribution, campaign latency, residual effects, latent conversions, indirect campaign effects, post-campaign effects. Whatever you want to call it, here are some WebTrends solutions for it. Part one of several.

We touched on the question of the residual effects of campaigns in our past post about Scruffy Campaign Attribution, which details the value and peculiarities of the obscure, deprecated WebTrends visitor history data element “WT.vr.ac.”  

In this post, we’ll describe custom reports for WebTrends Analytics that list your campaigns and, for each campaign, the amount of residual traffic, i.e. the number of visits by campaign responders AFTER the campaign-related visit. 

To report on campaign latency, you need these tools

  • A marker in the landing page URL.  For purposes of our discussion, the entry page URL must have “WT.mc_id = <campaignname>” as a query parameter.  We know you can use anything to mark a campaign, but we’re going to stick with WT.mc_id in this post because WT.mc_id is the only one that will get a visit’s campaign information saved in Visitor History.
  • Visitor History must be turned on for the profile, specifically Campaign History – because the reports we describe depend on extra parameters that are created by the Visitor History processing. 
  • Custom Reporting.  You need this capability in your WebTrends.

There are three campaign latency dimensions that we can work with in WebTrends.  They are based on Visitor History parameters:  WT.vr.rac, WT.vr.ac, and WT.vr.fc.  These parameter names are created internally by WebTrends when it sees WT.mc_id.  WT.mc_id is all you need to supply.  You should never put these WT.vr. parameters into your landing page URLs.  

“Most Recent Campaign”

If the current visit is caused by a campaign, the Most Recent Campaign is the one associated with the current visit.  If the current visit is not caused by a campaign, it’s the most recent campaign used by that visitor, i.e. a previous visit, previous campaign. 

By the way, a campaign stops being the most recent campaign after 90 days (or whatever you have configured).   After 90 days, it’s possible for a visitor to have no “most recent campaign” because of this.

This custom dimension is built on the query parameter “WT.vr.rac“.  You probably don’t have to build it; it’s probably in your out-of-the-box WebTrends as “Most Recent Campaign ID”.

“Any still-active campaign”

This is all campaigns that the visitor responded to in the last 90 days.  A visitor can have more than one “active campaign” in their history.

When used in a report, this dimension is a list of various combinations of campaigns, separated by commas.  The report shows how many visitors during that time period had each combination of campaigns in their history.

Build this custom dimension on the query parameter “WT.vr.ac.”  (We referred to this one in the first paragraph and wrote a previous post on it, calling it “scruffy” – check the previous post to see why.)

“Initial campaign”

This is the first campaign the visitor ever responded to.  This might be the current visit, if the current visit is the visitor’s first-ever campaign. 

Initial campaigns do not expire – they are associated with that visitor forever. 

It’s important to note that, however, that being the first-ever campaign doesn’t mean Campaign ABC was responsible for the first-ever visit, which could have been a search engine visit, a type-in, an email from a friend, anything, including a campaign.  But not necessarily a campaign.

Build this dimension on the query parameter “WT.vr.fc

 All the above are in the WT Analytics documentation, and the reports they produce are what you’d expect.  The problem with those straightforward reports is that you want to see latency, i.e. later visits.  This isn’t what you get.  All of the campaign history parameters count the current visit if the current visit is campaign related.   You’ll see spikes for “Most Recent Campaign” and all the others whenever you do a campaign because of the current-visit issue, and real latent campaign visits will be masked.

So here’s the trick that produces much more interesting reports.  Get rid of visits that are currently coming through campaigns.  Report on just visits that came to the site by type-ins, bookmarks, searches, friend-to-friend emails (not email campaigns), mentions on other sites, Tweets.  By reporting on the previous campaigns just for those non-campaign sources, you’ll have a far better idea of residual campaign effects.

The custom filter that makes it work

“Current visit is a campaign visit”

Build this custom visit filter based on the entry page query parameter “WT.mc_id=*  (WT.mc_id with any value)

Note that this custom filter is a visit filter.  It is built on Entry Page with a query parameter specified.  Not on the simple “query parameter” foundation (which would be a hit filter).   Being a visit filter is critical – you want to ignore entire visits.

You will be using this filter as an “exclude”.

And the final touch, a long sessionizing threshold

We suggest 120 minutes or longer for sessionizing in order to keep data noise to a minimum. We wrote a post on the length of the sessionizing timeout, and we really recommend that you use a long timeout when you are studying campaign latency.  Why?  Because the second half of an interrupted visit looks like a latent visit for the campaign that caused the first half of the visit.  That’s not what you want to be watching if you are interested in true return visits.  So we suggest keeping the number of interrupted visits to a minimum by using a nice long timeout.

Put it all together in custom reports

Three reports.  One of the above dimensions for each report.  The above filter applied as an exclude.

For all the above, measures should be, at minimum, visits and conversions.  The definition of Conversions, of course, will vary from site to site.  This Outsider post on creating custom conversion measures might be of interest.

POSTSCRIPT

Some cynicism about latency

We’re not totally convinced in the first place that the “most recent campaign” deserves much credit for a later visit.  “First campaign ever” on the other hand might deserve some credit for subsequent activity, because that first campaign may have introduced the visitor to the site, and that’s a very important role.  “Most recent campaign” makes sense for some web sites and certain kinds of campaigns, not so much for others.  It’s up to you, dear reader, to decide whether you are in the “some” or the “other” category as described above.  

Unreliable data

Just to remind you of this unhappy fact of analytics life … Campaign latency reporting relies on persistent cookies no matter what analytics tool you’re using.  Therefore, campaign history is gonna under-report actual residual behavior.  The first campaign visit often gets disconnected from later visits.  Because people delete cookies.  They use more than one computer.  And so on.  The more time has gone by since a given campaign visit, the more likely it is that the cookie deletion problem has made the connection between a visitor’s visits gone, gone, gone.    

Not just campaigns

Need we mention – all of the above can be done in WT Analytics for Search-related visits.  WebTrends has visitor history parameters for all search, paid search only, and organic search only.  Do a search in the documentation for one of the Visitor History parameters above and you’ll land in the section that lists all the VH parameters.