Reminder: What the SDC Tag Builder can do for you

If you’re using anything other than WebTrends’ TagBuilder tag to track mailto’s, downloads, offsite links, form buttons (and many other things), it’s time to review what it does.

We’ve seen a lot of “How can I track …” questions lately that can be readily answered by one answer:  “Use the latest SDC tag, it will do what you want and more.” 

Webtrends’ TagBuilder creates your tag for you, ready to be dropped into your site.  It has some powerful advanced features that take a lot of page customization work off your plate entirely.


Here is a quick list of many of the possibilities in the Additional Options section of the TagBuilder.  If any of these are news to you, go to and take a close look.

  1. Off-site links automatic tracking – the tag looks for links going somewhere else and records clicks on those links.  No need for passing those clicks through a redirect or using ondown/onclick coding on each offsite link.   They all get automatically picked up.  Woo hoo.  Saves the day when your marketing department adds new offsite links without telling you.
  2. Untaggable download files tracking – Tracks clicks on links that go to file types that cannot hold a tag:  .txt, .pdf, .whatever.  Tracking links to files that cannot be tagged is one of the downsides of using javascript page tagging, but it’s not a problem with the TagBuilder tag.  You get to choose what file types get tracked, of course.  This is another lifesaver because those prolific pdf writers at your company don’t need to inform you when they add a new one to a page.  (Important note – we purposely used the phrase “links that go to files” because that’s all SDC does, is track clicks on those links.  If a link to a PDF exists on somebody else’s site, people will request that PDF without SDC being aware of it.  Unlike server logs.  Thank you Michael for reminding us.)
  3. Form submit button clicks – Captures all clicks on form “submit” buttons, four common types of them:  (they covers 99% of situations, in my experience):  a)  <form> tag with method=get, b)<form> tag with method=post , c)  <input> tag, no enclosing <form> tag , d)  <button> tag, no enclosing <form> tag.  No need for special coding on form buttons.  Tracking form conversion becomes a certainty if you don’t always use thank-you pages.
  4. Anchor link tracking (those # suffixes that have to do with within-page links).  Great for understanding things like the popularity of individual questions on a FAQ page.
  5. Clicks on image map areas – no need for individually altering the code of image maps’ area-by-area hyperlinks.
  6. Mailto: clicks automatic tracking  (hyperlinks using the mailto: protocol).  No need to pass these through a redirect or use ondown/onclick code.  This is great for those long, constantly changing lists of salespeople on your Contact Us page.
  7. Javascript: clicks get automatically tracked.  Automatically tracks hyperlinks that use the javascript: protocol).  No redirects or ondown/onclick coding for each of these hyperlinks.  We actually don’t turn this one on very often in the tags we build, because it can result in double-tracking.
  8. Variations in how cookies are tracked:  you can get SDC to generate one cookie for your main domain and another for a subdomain if you want to.  Or not.  You can tell SDC to use a site-generated cookie instead of the WebTrends cookie, or use a session cookie instead of a persistent cookie.  The latter is handy for government sites that don’t allow persistent cookies.
  9. Extract part of a cookie value and put it into a parameter (that can be the basis of reports).  Does a cookie contain the data of the first visit, for example?  Grab it and turn it into an analyzable parameter with this option. 
  10. Rename (i.e. map) existing parameter names to WebTrends auto-report parameter names, for example record parameters such as “prodcat=15” as “WT.cg_n=15”.  Another example would be your on-site search engine’s unchangeable parameter names for “number of results found” or “keyword” on the results page URL.  This is a life saver if you are tagging an existing site that can’t be re-engineered to work with those WebTrends auto-config reports.
  11. Divert data for a subdomain to a completely different dcsID.  This one saves money and keeps dev-site, UAT-site, or staging-site data out of your analysis.  It eliminates the need to create filters in WebTrends reporting that filter out your dev or staging site (thereby avoiding dev or staging site hits being applied to the license quota, as long as you don’t analyze the diverted data).
  12. Multi-send data to WebTrends and also to your Ad Director or Quantcast account – no need for a separate tag for these two products.  Hey WebTrends, keep ’em coming in this department!

All of the above are individually activated in TagBuilder UI.  You turn on the ones you want, then the TagBuilder spits out a tag that you just drop into your web site. 

The TagBuilder absolutely changed our lives here at Outsider Un-Central.  It’s always surprising  to see that not everybody knows about it.  We hope this post changes a few more lives out there.

Oh, I almost forgot.  A nice touch in this tag is that each different event type gets its own little parameter that identifies the event type.  It’s a simple parameter, WT.dl, that contains a value corresponding to the event type that’s tracked.  For example, the parameter WT.dl=24 appears in every hit that is an offsite link hit, and WT.dl=23 appears on all hits that involve a mailto: click.  This little detail makes it easy to build filters for event types.  The list of WT.dl values is here.

(Please note that if you are already using the dcsMultiTrack functionality to do any of 1-7, you’ll have to do a little cleanup before taking advantage of the TagBuilder tag.  Please call WebTrends for some guidance.)

Cool Custom Dimension: Banish unneeded prefixes from Referring Sites reports

Clean up the Referring Sites report by stripping off unneeded domain prefixes belonging to server clusters or data center IDs.

This dimension simplifies Referring Site reports that contain a lot of subdomains, server clusters, or data center identifiers (I’m calling them prefixes) at the beginning of the site name.

For the referrer Yahoo, for example, the Referring Site report can look like this if you are running ads on Yahoo’s network:


All that server cluster information at the beginning of the subdomain makes it hard to see how many visits came from the Yahoo mail site.   Here’s the same list with the Yahoo mail referrers highlighted below. 


It’s a mess.

What we really would like to see instead of the above is a collapsed list that shows only three parts of the domain name, not all four or five:, or in this case, instead of all the craziness.   We want all the junk to the left gone, aggregated into a single line item like this:


This can be done with a custom dimension that strips off everything except the rightmost three parts of the site expression.    Instead of what’s on the left, above, we want the consolidated version on the right. 

Well, it’s quite easy to lop off all that junk.  Here are the steps.

  1. Create a new custom dimension called “Referring Sites, limited to three elements” or whatever you want to call it. 
  2. In the “Based On” screen, choose
    “Referring Site (eg:”
  3. Click on the button called “Advanced”
  4. basedon

  5. The Based On screen will refresh with more choices.  Choose Regular Expression and enter this magnificent regex:




 That’s it, save it. 

(By the way, while you were in the Advanced version of Custom Dimensions, did you take a look around?  That Advanced button gives two ways to show, in your reports, just a portion of a dimension value.  Very handy.  We’ve discussed the Advanced button before and also used it in the Display Google Organic Ranks post.)

Use this dimension instead of the out-of-the-box Referring Sites dimension whenever you want to limit the number of domain elements to

And before you get all impressed about what I, rocky, can do with regex … it was entirely Mister Peabody’s work and it took him about 3 minutes.   🙁

By the way, this simplified Referring Site dimension is great for evaluating the performance (i.e. the quality of the traffic) of all the Yahoo properties when you are showing ads on their network.  Just use the simplified Referring Sites dimension as the primary one, and use something like Content Groups as the secondary one.  Or a Scenario Analysis can be the second dimension; use anything that will tell you about key site actions.

Trust me, all Yahoo properties do NOT perform the same, not by a long shot.