Cool custom report: scruffy campaign attribution

Partial campaign attribution is a holy grail for marketing analysts. WebTrends has an undocumented way to make some headway.

The Scene

You’re in the basement of your house looking at a bag of old clothing left behind by the previous tenants.  Idly, with barbeque tongs and oven mitts you pull out item after item.  At the bottom, you hold up what looks like an early Fugazi roadie tee shirt, all skanky and moldy.  Wow.

The Analogy

This particular cool custom report is like that — all-but-abandoned, in dire need of being worked on, likely to fall apart at any moment, and possibly extremely cool. 

The Outsider went down to the basement after the recent WebTrends Lunch-n-Learn about “campaign attribution.”  The Outsider remembers an old visitor history parameter, undocumented for the past couple years, that still somehow persists in version 8.5 — it’s WT.vr.ac. 

The Details

“.ac” stands for “active campaigns.” 

“Active campaigns” means “all the WT.mc_id campaign IDs that were still active at the time of the visit.”

Note that this is not “initial” or “most recent” or “the current visit.”  “Active” means “everything within 90 days.”  90 is the default value that is configurable in the .wlp file and the wtm_wtx.ini file, in this line:

 campaigndurationdays = 90

The value of 90 (or whatever) in this line seems to be unchanged by the recent campaign-lifetime settings that were added to 8.5.

Trying it On

If you have Visitor History turned on and you create a dimension based on WT.vr.ac (with measure “visits”), you’ll get a report where each row is a comma-delimited list of all the campaign IDs that were active at the time of the visit, along with the number of visits that had that particular list of campaigns still active in their visit history.  If you use a revenue or conversion dimension, you’ll have similar stats but associated with KPIs.

In other words, if you are looking at June data and somebody visited on June 10 and, during the previous 90 days, that same cookie-person had the April25, May07, and June03 campaigns in their history, they’ll appear as one visit with that combination of campaigns.   You’ll see a row for “April25,May07,June03” with at least one visit counted.  Or something like that.

No, this info is not available in the Visitor History Table export that we’ve described previously.

The Implications

If you’re willing to put in the time, you have the opportunity to analyze this information in nifty ways.  It’s especially productive if one of your measures is some kind of conversion or revenue. 

To properly analyze, you’ll need to export the results to Excel etc for some further crunching to get the good stuff:

  • Partial attribution, weighted any way you want – 20% to the oldest campaign, 70% to the latest, and the other 10% split between all others?  100% to the latest and another 100% split among all the previous ones?
  • Understanding whether lotsa campaign responses are better (in terms of KPIs) than a few, versus the other way around.  Seriously, what if you see that people with 10 campaign responses in the last 90 days never bought anything, while people with 2 responses made up the bulk of the buyers?  Ouch.
  • Noticing that the May campaign appears in conversions disporportionately – OMG you could actually be talking about causality if you find this one.  You are such a good debater, er, analyst. (Small USA election campaign joke there, sorry.)

Pause.  Curb your enthusiasm.

The Flaws

Did we mention that this is a scruffy VH parameter?  It has flaws, which are probably the reason why WebTrends deep-sixed it years ago while thankfully (for us) not completely destroying it.

  • Within a given row, the campaign names appear in no sensible order — definitely not chronological or consistent in any way.  The order isn’t even dependent on the alphabetical order of the underlying campaign GUID.
  • It’s entirely possible to see the same exact combination of campaigns listed more than once, but differently-ordered each time.  Crazy.  Requires more work to sort it out, yes.

But in our tests, despite these flaws, the WT.vr.ac parameter works.  We haven’t done really extensive tests and haven’t played with Visitor-type measures.  We hope other people do and let us know about what they find.

The Consequences

We, the WebTrends Outsiders, are hoping that within WebTrends Inc there is a flurry of e-mails about this post.  What is this thing, who overlooked it when we tried to wipe it out, who left it in the basement, now what?

As for “now what” we’d like to see WebTrends consider whether extended and/or partial campaign attribution should be tried on for size.

 

 

Server logs or SDC javascript tracking?

Choosing between server logs and javascript tagging for web analytics tracking, using 18 yes-no questions. And, raising the question of whether you should use BOTH.

Applies to:  software

The Outsider talked about this topic a while ago at the end of the AVG Linkscanner posting.  That posting consisted of lists of the pros and cons of the two data collection methods.  “Pros and Cons” is the structure used by most sources that we’ve seen, although our lists of course are more complete and correct than others’ … 🙂

This post on the other hand is like the first question of a decision tree.  Or like an online personality test.  This post consists of oversimplified if-then stuff that, despite the oversimplification, might float some important issues a bit closer to the surface for you.

To continue the personality test analogy, we have to acknowledge that any personality test worth its salt will produce conflicting feelings while you take it.  The happy secret in the analytics world is that it’s possible to use WebTrends software with both types of data, even within the same WebTrends license, without messing up licensing costs.  We’ll do a post soon about the so-called hybrid approach.

Are you ready for oversimplification and conflicting feelings?  Here’s our best shot at an if-then list for data collection method choices, if you are using the software. 

  • Is owning and operating a dedicated server for SDC collection out of the question? Same for sharing somebody else’s SDC server? Then it’s server logs for you (or the On Demand service).  (Obviously I am putting the easy ones at the top of the list, but it’s surprising how often people go “what?  I have to have a server?”)
  • Does your site rely on visitors crossing over to other domains that you don’t own? For example, is your check-out process hosted by a shopping service? If so, SDC may be your only way to get visit information all the way through to the receipt – if the service is willing and able to add your SDC tags to their checkout pages.
  • Do you have no access to the site’s code, or no way to get the SDC tag onto the site pages? If it’s all out of the question, then server logs are your only resort.
  • Is your site made up of more than one domain? Do your visitors often go to more than one of your domains during a visit?  And do you want to report on all those page views as one visit? Then you need the SDC server and tags which can magically give a visitor the same cookie no matter what domain they are on.
  • Does your site use a lot of redirects that have to happen without pause yet need to be tracked, or does it use immediate meta-refreshes? For example, do you have a lot of vanity domain names that redirect to your main domain? Server logs are the only way to track these reliably.
  • Is it important to have complete and correct path analysis? Then you’ll need SDC for several reasons. a) It collects every page viewed, including those that elude log files because they are served from a cache (example: back-button page views).  b) It collects clicks that jump off to other sites, form submittal steps, mailto steps, downloads, and other “invisible” things. c) SDC follows your visitor across every domain you’ve put your tag on. d) Finally, SDC cookie-matches a first-time visit’s initial hit to the rest of the visit, avoiding visit breakup in those cases where the IP address changes between the first and second hits. 
  • Does your site push technology boundaries, causing you to want to know all about your audience’s screen resolution, Java version, and so forth? SDC is your answer.
  • Are you worried about somebody pirating your pages and displaying them on their site? If they’re dumb enough to not remove the SDC tag code, then SDC will help you find them because the SDC beacon sends signals from wherever it may be.
  • Do you get a lot of spider and bot traffic that you don’t care about, and the act of filtering it out is driving up your WebTrends page quota? Then SDC tagging could save you some WebTrends license money, because SDC logs usually don’t collect spider hits.
  • On the other hand, do you really, really want to know about spiders and bots and what they are doing on your site?  SEO mavens for example want to know how quickly, recently, or thoroughly the various spiders have been around.  Techs care whether Cuil’s overenthusiastic bot was responsible for a recent server slowdown.  If so, server logs are your only way to track bot and spider requests (although too many of them disguise themselves too well).
  • Is it difficult to get server logs from your hosting provider? SDC creates its own log, hopefully in a more accessible place for you.
  • Do you lack confidence that your programmers will get the tag onto every page, including in the future as the site changes? No tag, no record, remember. Server logs on the other hand are basically automatic and will record every request.
  • Is there much chance that your visitors will often click away from a page before it completely loads (and therefore before the SDC tag fires)? For example, does your site’s audience tend to be on really slow connections, or are your pages ultra-dense? Then server logs, which capture requests right when they happen, will be more reliable than SDC tags, which if installed at the end of the page won’t fire until the whole page has been received (not rendered, but received).
  • Is it really important to know how quickly the server is responding to file requests? Server logs are your only choice. But only IIS server logs.  (Apache logs will record this info but WebTrends can’t cope with that log field.)
  • Do you need fairly exact numbers for bandwidth use? Server logs will collect incoming and outgoing bandwidth use for every single request, including images. Given complete server logs, WebTrends will add everything together for you and give you hour-by-hour bandwidth consumption stats.
  • Do you care about broken links to images, or to style sheets, scripts, and other miscellaneous files? Link-checking software is available, but server log files also collect this information and WebTrends has an error report that will give you a complete list.  SDC tags ignore calls to images etc entirely, whether broken or not.
  • Do you feel technically up to the task of tracking Flash by placing calls within your Flash applications? If not, server logs will give you minimal Flash tracking automatically – by recording requests for the Flash .swf files.
  • Do you want to look at historical data for your site?  Your old server logs are probably still there.

That it.  Are you conflicted?

If you’re not conflicted, we offer this.  The Outsider seems to always add little postscripts, so here we go.  It’s possible to trick server logs into collecting some or all of the specialized SDC information like screen size, because it all boils down to javascript code on your page.  It’s also possible to trick SDC into getting some of the unique server log information.  We acknowledge this, and wrote our little questions for the less technically adventurous.

Getting reports to display bar graphs in data columns

You can sort your reports on one measure and have other measures displayed as bars as well as numbers. The result is a quick visual display of relationships.

A couple weeks ago Sean Browning was messing with some WebTrends reports during one of his WebTrends Lunch’n’Learn webcasts.  As usual, at least one WebTrends Outsider was lurking in the audience.

One of Sean’s reports showed a bar graph in the fourth column — a colored horizontal bar in each row, its length proportional to the stat for that measure in that row.

You’ve probably seen those bars in WebTrends tables and haven’t given them a second glance.  In the out-of-the-box reports and the defaults for any custom reports, the horizontal bars are always set up to be in the first (the leftmost) column of the table.  That’s the column which by default is how the whole table is sorted.  That’s also the column that’s the basis for the big bar graph just above the table.  So those bars-within-the-column are just a sideways version of the frequency bar graph in the same report.  Bo-rrrr-ing.

Sean’s table however had the bars in the third column, the column that showed “length of visit.”

Suddenly things were interesting.  Instead of showing a ho-hum decreasing array (if the bars had been based on the first column), the length of these bars varied wildly from row to row.  You could instantly see that certain popular items (popularity meaning “at the top of the list”) had really pitiful time-spent-on-site statistics.  That’s worth knowing. 

This report wasn’t showing any NEW data.  But it was showing existing data in a visual way.  And visuality often yields insight. 

(Yes, “visuality” is a word.  I looked it up.)

Think about how helpful it would be to see your report sorted on one measure while a bar graph happens based on a different measure:

  • Entry pages sorted by popularity, with a bar graph for “time spent on site”
  • Search terms sorted by popularity, with a bar graph for “# of pages in the visit”
  • Pages sorted by popularity (visits), with a bar graph for “views”
  • Referrers sorted by popularity, with a bar graph for “number of leads” or “revenue”

How-to

Here’s how to get those bar graphs to appear in the measures column of your choice, for a given report. 

  1. Go to Web Analysis >> Report Configuration >> Report Designer >> Templates and open the template you want to work on. 
  2. Find the report in which you want an inline bar graph.  Select or highlight it. 
  3. The main part of the screen will change.  Toward the bottom you’ll see settings that apply to the report’s table display.  Every column from the 1st to the nth will have two choices:  radio buttons for choosing which measure should display in that column, and a check box for whether there should be an in-line graph in that column.  That’s your baby right there. 
  4. Check the box under the column/measure where you want the in-line graph to appear.   Ta-dah! 

,

Beyond the how-to — Think about the sorting measure

While you’re selecting your in-line graph measure, also think about which measure you want to be in the first column.  Remember, that first column is the default sorting column for the table.  The visual variability of in-line bar graphs will be most helpful if you choose the sorting column properly.   Do you want to see how visit length varies as visits decrease, or as page views decrease?  There could be a big difference. 

This kind of choosing is where you get to be a bit of an analyst, not just a GUI jockey.

Okay, now for the gotcha

This inline bar graph thing is kinda recent, and not all WebTrends out-of-the-box (“built-in”) reports have it available!  But all custom reports do, as far as we can tell (let us know if you find exceptions). 

For the old standard built-in reports, if you look at them in the Template Designer you’ll just see a dumb little table that says “Sample Table Entry” for each row instead of the radio buttons and checkboxes we mentioned above. 

For example, the Pages report doesn’t have inline bar graphs available.  Not the built-in, out-of-the-box Pages report.   That report has been around since Log Analyzer.

Not to worry, it’s an easy fix. 

Just use the custom report function to make a modernized custom version of that report.  It can be identical in dimensions and measures to the original, but because you’re using the custom interface, you get the perk of the in-line bar graph. 

When you create the custom version of the built-in report, it’s a good idea to give it a slightly different title, like “Pages (custom)” or “Pages (cr)” so it won’t get mixed up with the fossilized one.  And — be bold, be brave — remove the old fossil from the template.

Future?

We’ve heard from an unreliable source that those built-in reports will be reprogrammed in a future release so that all reports will have this capability, even if they are the oldie-goodies that predate the custom reporting UI.  So we hope to someday come back and delete the crazy part of this posting – the part about having to convert built-ins to custom.  We hope that, at the same time, the in-line bar graphs will be added to the custom report definition interface, with the template designer being used just for overrides.  It’d be nice to have all aspects of a custom report’s design in the same place.

In the meantime, the extra bit of kludge is worth it.